विशाल SaaS-Lighting - IT उपयोगकर्ताओं को कैसे "gaslighting" किया गया

 (unworkableideas.com)
7 पॉइंट द्वारा GN⁺ 2025-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SaaS मॉडल ने कभी ‘जितनी ज़रूरत हो उतना ही भुगतान करो, और टेक्नोलॉजी की जगह बिज़नेस पर ध्यान दो’ का वादा करके IT उद्योग को प्रभावित किया था, लेकिन वास्तव में यह ग्राहकों को lock-in करने वाली संरचना में बदल गया
  • प्रमुख vendors ग्राहक संतुष्टि से अधिक लगातार भुगतान बनाए रखने और डेटा संग्रह पर ध्यान देते हैं, और ‘Customer Success Manager’ भी आखिरकार churn रोकने की भूमिका तक सीमित हैं
  • पूरे उद्योग ने ‘best practice’ के नाम पर बदलाव और innovation से बचते हुए, नतीजतन एकरूप और साधारण software ecosystem को बढ़ावा दिया
  • SaaS बाज़ार 1980 के दशक के अमेरिकी shopping mall की तरह ज़रूरत से ज़्यादा नियंत्रित और पूर्वानुमेय ढांचे में बदल गया है, जहाँ बड़े platforms मकान-मालिक और दुकान दोनों की भूमिका निभाते हैं
  • असली समाधान वह एक जैसा सिस्टम नहीं है जिसे सब इस्तेमाल करते हैं, बल्कि ऐसा information system बनाना है जो संगठन के अनुरूप हो, और यह self-hosting जैसे वैकल्पिक तरीकों से संभव है

SaaS मॉडल का वादा और वास्तविकता

  • SaaS ने शुरुआत में ‘pay as you go’, ‘टेक्नोलॉजी से ज़्यादा बिज़नेस पर फोकस’ जैसे आदर्शों के साथ IT operations को अधिक efficient बनाने का वादा किया
    • उपयोगकर्ताओं को इस संदेश से प्रभावित किया गया कि वे पूंजी और समय बचा सकते हैं और तकनीकी प्रबंधन का बोझ घटा सकते हैं
  • लेकिन व्यवहार में Microsoft, Google, Intuit जैसे बड़े providers ने customer-centricity से अधिक customer dependency को प्राथमिकता देने वाली संरचना विकसित की
    • हर interaction के बाद customer satisfaction survey कराया जाता है, लेकिन यह भी big data collection का एक और माध्यम भर है
    • survey के नतीजे गौण हैं; असल इच्छा सिर्फ यह है कि ग्राहक बने रहें और भुगतान करते रहें
    • एकत्रित डेटा का उपयोग केवल किनारों पर होने वाले incremental improvements के लिए किया जाता है

Customer Success Manager का विरोधाभास

  • लगभग हर SaaS कंपनी ने Customer Success Manager की भूमिका बनाई है
  • इन्हें accounts पर नियुक्त किया जाता है ताकि वे onboarding में मदद करें और churn रोकें
  • यहाँ ‘success’ का मतलब संगठन की वास्तविक सफलता नहीं, बल्कि उत्पाद का पर्याप्त उपयोग करवाना है
  • उपयोगकर्ताओं के लिए उपयोगी उत्पाद बनाना अपने आप में बुरा नहीं है, लेकिन SaaS business model समय के साथ customer success नहीं बल्कि submission और inertia पर आधारित संरचना में बदल गया
  • एक बिंदु के बाद customer base और product इतने बड़े हो जाते हैं कि बदलाव असंभव हो जाता है

Safety in Numbers - संख्या की सुरक्षा का भ्रम

  • कई कंपनियाँ SaaS इसलिए अपनाती हैं क्योंकि ‘बाकी सब भी यही कर रहे हैं’ वाली मानसिकता और network effects काम करते हैं
    • अगर हर कोई यही कर रहा है, तो यह अच्छा या कम-से-कम काफी अच्छा minimal-resistance path लगने लगता है
    • network effects में मूल्य है, लेकिन संख्या केवल एक सीमा तक ही सुरक्षा देती है
  • संख्या अदृश्य जोखिमों को छिपा देती है, खासकर black swan प्रकार के जोखिम
    • ऐसे जोखिम दुर्लभ होते हैं, लेकिन इतने विनाशकारी हो सकते हैं कि कोई उनके बारे में गंभीरता से सोचता ही नहीं
  • backup, disaster recovery, business continuity systems single-system failure से तो बचा सकते हैं, लेकिन context और know-how के नुकसान से नहीं
  • असली समस्या loss नहीं बल्कि accumulation है
    • बहुत सारे programs, API, integrations, और sophisticated systems के रूप में छिपी अत्यधिक जटिलता
    • context recovery system जैसी कोई चीज़ मौजूद नहीं है, जबकि सफल संगठन डेटा नहीं बल्कि context पर निर्भर करते हैं
    • terabytes डेटा का कोई मतलब नहीं, अगर यह न पता हो कि डेटा क्यों रखा गया है, उसका अर्थ क्या है, और उसका इस्तेमाल कैसे करना है

सूचना-अधिभार और निर्णय लेने का जाल

  • सूचना और content अनंत और probabilistic हैं, और ज़रूरी नहीं कि वे हमेशा पूर्वानुमेय हों
  • अधिक जानकारी बेहतर decision-making की ओर नहीं ले जाती; वह अक्सर सिर्फ और अधिक डेटा देती है
  • यह अज्ञात और जोखिम के डर को और बढ़ावा देता है
  • निर्णय लेने से पहले सारी जानकारी जानना संभव नहीं, लेकिन अज्ञात और अनिश्चितता के सामने ‘best practice’ अपनाना एक आरामदायक सुरक्षा-कंबल जैसा लगता है

Undifferentiated Best Practices — बिना भेद वाली best practices

  • पूरे उद्योग में ‘best practice’ templates पर अंधविश्वास जैसा भरोसा है
  • best practice की समस्या यह है कि वह मान लेती है कि दुनिया बदलना बंद कर चुकी है
    • वास्तविक दुनिया स्थिर नहीं है; वह लगातार बदलती है और निरंतर सुधार और विकास की मांग करती है
  • template-based best practices को आँख बंद करके अपनाना श्रेष्ठ बनने का रास्ता नहीं, बल्कि औसत साधारणपन की ओर जाने का रास्ता है
  • ‘पहिया फिर से मत बनाओ’ वाली दलील का दुरुपयोग किया जाता है
    • दावा यह किया जाता है कि पहले से हल हो चुकी समस्याओं पर समय और मेहनत लगाने की ज़रूरत नहीं
  • वास्तव में यह तरीका केवल प्रतिस्पर्धियों के बराबर parity हासिल करने में ही माहिर है
  • यह दृष्टिकोण bland mediocrity को बढ़ाता है और वास्तविक भिन्नता या प्रगति को रोकने वाली संरचना बन जाता है

Bland and Generic Applications — एकरूप software ecosystem

  • commercial software ecosystem को देखें तो हज़ारों categories में हज़ारों applications हैं, लेकिन फिर भी वे अक्सर note-taking या calendar applications के बस अलग-अलग रूप ही देते हैं
    • कुछ programs अधिक सुंदर या अधिक intuitive लग सकते हैं, लेकिन समस्या की परिभाषा और approach लगभग समान रहती है
  • software बार-बार उसी तरह की हल की जा सकने वाली समस्याओं को इसलिए हल करता है क्योंकि जो समस्याएँ बची हैं, उन्हें तकनीक से हल करना वास्तव में बहुत कठिन है
    • communication और collaboration ऐसी बारीकियों और सूक्ष्मताओं से भरे हैं जो digitalization का प्रतिरोध करती हैं
  • यह सिर्फ SaaS vendors तक सीमित नहीं; ज़्यादातर software कंपनियाँ product marketing और sales के लिए SaaS bandwagon में शामिल हो गई हैं
    • paid membership की ओर खींचने के लिए बस पर्याप्त features देने वाले free versions
    • और फिर good, better, best वाले standard 3-tier subscription options
  • communication tools जोड़ने से communication की quality बेहतर नहीं होती, बल्कि communication की मात्रा बहुत बढ़ जाती है, जिससे noise और fatigue बढ़ते हैं

Let’s Go to the Mall — SaaS और 1980 के दशक के shopping mall की समानता

  • SaaS अब 1980 के दशक के अमेरिकी shopping mall जैसी तकनीक बन चुकी है
    • बहुत महंगी, पूर्वानुमेय, और लगभग हर mall में लगभग वही चीज़ें
  • यह कोई dynamic market नहीं, बल्कि बहुत नियंत्रित market है
    • landlord platform खड़ा करता है, और retailers इस शानदार लोकेशन पर उमड़ पड़ते हैं ताकि भारी मुनाफ़ा और scale advantages पा सकें
    • mall का किराया उठा सकने वाले retailers बेहद नियंत्रित अनुभव उपलब्ध कराते हैं
  • 1980 के दशक के mall साहसी प्रयोग और जोखिम उठाने की जगह नहीं थे; जोखिम सिर्फ lease agreement पर हस्ताक्षर करना था
  • Google और Microsoft mall की दुकानों की तरह भी हैं, और साथ ही landlord बनकर पूरे mall experience को नियंत्रित भी करते हैं
  • Apple अपना खुद का mall चलाता है और ज़्यादा चमकदार है, लेकिन अलग नहीं
    • आज physical malls में Apple Store traffic न लाए तो वे लगभग ghost town बन जाएँ
  • एक समय के बाद संस्कृति mall experience से थक गई, और पूरे अमेरिका में छोड़े गए malls भर गए
    • यह मॉडल एक सीमा तक काम करता है, लेकिन रुझान बदलते रहते हैं
  • सावधानी से चुने गए products वाली छोटी दुकानें सामने आईं और भीड़ खींचने लगीं
  • information technology का भविष्य भी बहुत हद तक ऐसा ही है
    • महत्वपूर्ण यह नहीं कि आपके पास वही सिस्टम हो जो बाकी सबके पास है
    • महत्वपूर्ण यह है कि आपके पास अपने लिए उपयुक्त information system हो

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-27
Hacker News राय

  • यह चर्चा करती है कि जैसे उपभोक्ता खाने या कपड़ों की ‘असल कीमत’ चुकाना नहीं चाहते, वैसे ही वे सॉफ़्टवेयर की असली कीमत देने से भी कतराते हैं।
    पहले Postman जैसे टूल एक बार में $40 में खरीदे जाते थे, लेकिन अब संरचना ऐसी है कि $30/माह का subscription देना पड़ता है।
    SaaS का फायदा यह है कि यह हमेशा नवीनतम version बनाए रखने में मदद करता है।
    लेकिन सॉफ़्टवेयर development मूल रूप से आर्थिक रूप से महँगा काम है, और open source contributors की बिना भुगतान वाली मेहनत के कारण उसके मूल्य को कम करके आँका जा रहा है।

    • इसके जवाब में सवाल उठाया गया: “अगर version 4 ही काफी है, तो बार-बार upgrade क्यों करना चाहिए?”
      पिछले 20 वर्षों में बहुत बड़ी मात्रा में सॉफ़्टवेयर बना है, लेकिन महसूस होता है कि क्रांतिकारी breakthrough लगभग नहीं हुए।
      यह भी कहा गया कि कंप्यूटर 10~20 गुना तेज़ हुए हैं, फिर भी चीज़ें उल्टा और धीमी व जटिल हो गई हैं।
    • यह ज़ोर देकर कहा गया कि सॉफ़्टवेयर, खाने की तरह अनिवार्य वस्तु नहीं है।
      आज का सॉफ़्टवेयर अक्सर उपभोक्ताओं पर थोपा जाता है और data collection व surveillance के लिए Trojan horse की तरह काम करता है, ऐसी आलोचना की गई।
      उपभोक्ता खाना, पानी और रहने की जगह के लिए पैसे देते हैं, लेकिन सॉफ़्टवेयर के लिए नहीं देना चाहते।
    • यह दावा किया गया कि Postman महँगा इसलिए नहीं है कि development cost अधिक है, बल्कि VC repayment structure की वजह से है।
      कहा गया कि अगर निवेश और टीम का आकार तार्किक होता, तो एक साधारण curl GUI के लिए Adobe-स्तर की कीमत लेने की ज़रूरत नहीं पड़ती।
    • यह याद दिलाया गया कि पहले packaged software में upgrade discount मिलते थे, और उसे second-hand बेचा भी जा सकता था।
      यह भी कहा गया कि SaaS open source contributors को कोई अधिक compensation भी नहीं देता।
    • कहा गया कि Postman की समस्या सिर्फ developer livelihood की नहीं है, बल्कि corporate profit maximization के लिए product का जटिल होना और अपनी मूल सादगी खो देना है।
      यह भी कहा गया कि कंपनी पहले ही कई clients के बीच दिशा बदलती रही है, और Postman भी आखिरकार उसी राह पर है।

  • उम्मीद जताई गई कि “AWS डाउन हो गया” जैसी अतिरंजित पोस्टें गायब हों और बातचीत फिर सामान्य चर्चा पर लौटे।
    याद किया गया कि पहले on-premises servers से भी काम आराम से चल जाता था, और वह आज की तुलना में कहीं अधिक efficient था।
    अब समय ऐसा है कि developers को AWS भी समझना पड़ता है, और security risks के साथ LLM के ज़रिए knowledge leakage की चिंता भी करनी पड़ती है।
    यह भावना व्यक्त की गई कि तकनीकी प्रगति ने उल्टा dystopian development environment बना दिया है, और सरल व सहज UX की कमी खलती है।

  • यह तर्क दिया गया कि ज़्यादातर कंपनियों के लिए email, calendar, VPN, CRM आदि में ‘काफी अच्छा SaaS’ इस्तेमाल करना व्यावहारिक है।
    Google Workspace, HubSpot और Power BI जैसे टूल पहले के offline products की तुलना में कहीं बेहतर लगते हैं।

    • लेकिन इसका जवाब दिया गया कि “30 साल पहले ही पूरी तरह बन चुके office software के लिए प्रति-उपयोगकर्ता किराया देना अनुचित है।”
    • HubSpot mobile app के बारे में व्यक्तिगत अनुभव साझा किया गया कि उसमें बहुत bugs हैं और उसे चलाना असुविधाजनक है।
      यह माना गया कि छोटी screen पर बहुत सारी जानकारी दिखाना कठिन है, फिर भी अनुभव असहज लगता है।

  • SaaS में security features को अलग-अलग tiers में बंधक की तरह बेचने वाली संरचना की आलोचना की गई।

    • “SSO (single sign-on)” का उदाहरण देते हुए कहा गया कि सामान्य login भी पर्याप्त रूप से सुरक्षित हो सकता है।
      phishing का शिकार होना कंपनी की समस्या है, vendor की ज़िम्मेदारी नहीं, ऐसा कहा गया।

  • SaaS पर चर्चा में अक्सर उठने वाले ‘piracy’ मुद्दे को भी सामने रखा गया।

    • बताया गया कि SaaS ने कंपनियों को users पर लगभग पूर्ण नियंत्रण दे दिया, और Salesforce की adoption strategy की तरह इसे व्यक्ति→टीम→संगठन तक स्वाभाविक रूप से फैलने दिया।
      install की आवश्यकता न होने से adoption आसान हो गया।
    • विडंबना यह बताई गई कि FOSS समर्थकों ने जिस “service contracts से कमाई करने वाली दुनिया” की बात की थी, वह वास्तविकता तो बनी, लेकिन नतीजा और अधिक बंद ecosystem के रूप में सामने आया।
    • एक अनुभव साझा किया गया कि पहले एक startup में बनाए गए system को एक चीनी SaaS कंपनी ने source code समेत कॉपी कर लिया था।
      यह जोड़ा गया कि intellectual property theft आम है, लेकिन data में अंततः मुक्त होने की प्रवृत्ति होती है।
    • यह विश्लेषण भी दिया गया कि enterprise environment में piracy लगभग नहीं थी, इसलिए SaaS उस समस्या को हल करने के लिए बना मॉडल नहीं था।
    • 《Fundamentals of Data Engineering》 पढ़ते हुए यह समझ आने की बात कही गई कि web scraping, SaaS युग में ‘copying’ का नया रूप है।

  • यह समझाया गया कि SaaS अपने आप में बुरा विचार नहीं है, और जितना इस्तेमाल उतना भुगतान वाला ढाँचा तार्किक हो सकता है।
    समस्या यह है कि subscription model हद से ज़्यादा बढ़ गया है, और vendor lock-in के कारण data portability लगभग असंभव हो जाती है।
    AWS की ‘moat’ strategy की तरह, उपयोगकर्ता अपनी ही बनाई dependencies की वजह से बाहर नहीं निकल पाते।
    इसलिए सलाह दी गई कि core functionality को SaaS पर निर्भर नहीं करना चाहिए।

    • AWS Amplify को lock-in का सबसे खराब उदाहरण बताते हुए कड़ी आलोचना की गई।

  • यह कहा गया कि SaaS के सिर्फ नकारात्मक पक्ष पर ज़ोर देना संतुलित दृष्टिकोण नहीं है।
    B2B SaaS ग्राहकों को बड़े फायदे दे सकता है, बशर्ते competition बना रहे।
    vendors के पास churn रोकने के लिए product को लगातार बेहतर करने और नए features मुफ़्त देने की प्रेरणा होती है।
    दूसरी ओर, पुराने on-premises software में maintenance contracts महँगे थे और quality भी कमज़ोर थी, ऐसा याद किया गया।
    अंततः खरीदार को एक समझौता बिंदु चुनना पड़ता है।

  • यह कहा गया कि Photoshop या AutoCAD जैसे products में short-term subscription option होता, तो वह freelancers के लिए उपयोगी हो सकता था।
    लेकिन व्यवहार में subscription को अपनी सुविधा से चालू-बंद करना आसान नहीं है।

    • यह साझा किया गया कि Photoshop 6.0 का 2000 version खरीदकर आज भी आधुनिक PC पर इस्तेमाल किया जा रहा है, और वह DRM के बिना पूरी तरह काम करता है।
      ज़ोर देकर कहा गया कि एक बार खरीदना ही काफ़ी है।

  • यह विश्लेषण किया गया कि SaaS का मूल lock-in दो तत्वों के मेल से आता है।

    1. declarative और stable interface, 2) specialized operations team का support
      तर्क दिया गया कि इन दोनों को अलग (unbundle) करना चाहिए, और समझाया गया कि पहले हिस्से को शायद Nix पहले ही हल कर सकता है।
      बची हुई चुनौती self-hosting आधारित support business model बनाना है।
      यह विश्वास जताया गया कि तकनीकी रूप से यह संभव है, लेकिन अभी तक इसे वास्तव में लागू नहीं किया गया है।