Self-service डैशबोर्ड काम क्यों नहीं करते

• "self-serve dashboards" वास्तव में अच्छी तरह काम नहीं करते। ऐसा इसलिए है क्योंकि इंजीनियरों या डेटा वैज्ञानिकों को बिज़नेस यूज़र्स के लिए क्वेरी लिखने और डैशबोर्ड तैयार करने में बहुत समय खर्च करना पड़ता है।

"self-serve BI" काम क्यों नहीं करता

• SQL ही एकमात्र "self-serve BI" टूल है। लेकिन ज़्यादातर "self-serve BI" वेंडर SQL को किसी और चीज़ के रूप में छिपाने की कोशिश करते हैं।
• SQL क्वेरी लिखना ही वह एकमात्र बाधा नहीं है जो बिज़नेस स्टेकहोल्डर्स को डेटा क्वेरी करने से रोकती है। वे डेटा का मतलब, उसका स्रोत, उसकी गणना कैसे हुई, यह नहीं समझते, और न ही वे यह जानते हैं कि परिणामों की व्याख्या और सत्यापन कैसे किया जाए।

प्रयास 1: पारंपरिक "ड्रॉपडाउन और चेकबॉक्स" तरीका

• यह इंटरफ़ेस सिर्फ "SQL-by-mouse" की कोशिश भर है। यह SQL से बेहतर नहीं है; बल्कि अधिक धीमा, कम भरोसेमंद, अधिक सीमित है, और दूसरे टूल्स में सामान्यीकृत नहीं किया जा सकता।
• CFO जैसे लोग इस इंटरफ़ेस का उपयोग करके डेटा क्वेरी नहीं करेंगे। ऐसा इसलिए है क्योंकि उनके पास डेटा को समझने का संदर्भ नहीं है और वे परिणामों को लेकर आश्वस्त नहीं हो सकते।

प्रयास 2: text-to-SQL तरीका

• LLM प्राकृतिक भाषा को SQL में अनुवाद करने में लगभग जरूरत से ज़्यादा प्रभावी हैं। सवाल सही न भी हो, तब भी वे क्वेरी बनाने की कोशिश करेंगे।
• तकनीकी लोग समझ जाएंगे कि सवाल सही नहीं है और वे अधिक संदर्भ मांगेंगे। वे उपलब्ध डेटा के प्रकारों की व्याख्या करेंगे और सटीक व उपयोगी सवाल बनाने के लिए बिज़नेस टीम के साथ काम करेंगे।
• LLM "self-serve BI" का वास्तविक समाधान बन सकते हैं, लेकिन अपने मौजूदा रूप में नहीं। उन्हें अधिक संदर्भ की ज़रूरत है, और उन्हें अनिश्चितता व्यक्त करने व अधिक जानकारी मांगने में अधिक सक्षम होना होगा।

जो वास्तव में काम करता है

• "self-serve BI" की समस्या SQL नहीं, बल्कि डेटा का संदर्भ और अर्थ है। समाधान यह है कि इंटरफ़ेस चाहे जो भी हो, लोगों को उस डेटा के बारे में सिखाया जाए जिसे वे क्वेरी कर रहे हैं।
• टेक्निकल टीम से हर ज्ञान को दस्तावेज़ित करवाना काफी ओवरहेड पैदा करता है और वह जल्दी पुराना भी हो जाता है।
• "self-serve BI" का असली समाधान यह नहीं है कि गैर-तकनीकी लोगों के लिए BI को "self-serve" बनाया जाए, बल्कि यह है कि तकनीकी लोग बेहतर टूल्स का उपयोग करके बिज़नेस स्टेकहोल्डर्स की अधिक कुशलता से मदद करें।

बेहतर टूल्स के लिए सुझाव:

1. LLM को बिज़नेस स्टेकहोल्डर्स की बजाय तकनीकी लोगों को दिया जाए।
2. Python, R जैसे सुविधाजनक टूल्स का उपयोग करके डेटा को स्वतंत्र रूप से संभालने की सुविधा दी जाए।
3. तकनीकी लोग अपना काम आसानी से साझा कर सकें। notebooks और internal data applications को containers, dependencies, और infrastructure संभालने पड़ते हैं, इसलिए उन्हें साझा करना कठिन होता है।

[GN⁺]

Hacker News की राय

• एक कंपनी में BI tool से dashboard बनाए जा रहे थे। नंबर अजीब लगे तो query generator देखा, लेकिन query के कुछ हिस्से inner join थे या left join, यह बिल्कुल समझ नहीं आ रहा था
  वह dashboard बनाने वाले business analyst को भी नहीं पता था। असल में इरादा inner join का था, लेकिन left join चल गया, जिससे दिखाया गया डेटा वास्तविकता से एक digit तक बड़ा दिख रहा था
  उसी वक्त से मैंने SQL न जानने वाले लोगों के लिए SQL के ऊपर बनाई गई ऐसी abstraction layers पर भरोसा करना छोड़ दिया

  • 15 साल से ज़्यादा समय तक data engineering/data science teams लीड करने के अनुभव से कहूं तो, असल बात बिल्कुल यही है
    बहुत से लोगों के पास डेटा तक access होता है, लेकिन वे खुद डेटा, relationships, और अपने बनाए output का मतलब नहीं समझते
    पिछले 25 सालों में distributed/embedded engineers और scientists, self-service dashboards, low-code BI/data tools, और अब LLM-based text→SQL/visualization तक समाधान की तरह सामने आए हैं, लेकिन आखिर में वे डेटा की समझ की कमी और outputs पर भरोसे की समस्या हल नहीं कर पाए
    हालांकि SQL भी समाधान नहीं है। डेटा निकालने लायक SQL जानने वाले लोग काफी हैं, लेकिन data structure, schema, और सही उपयोग तक समझने वाले लोग कम हैं
    अनुभव के अलावा अभी तक ऐसा कोई tool नहीं है जो इस समस्या को हल करे, और LLM कभी यह कर पाएगा या नहीं, पता नहीं—ईमानदारी से कहूं तो संभावना कम लगती है
    dashboards KPI जल्दी देखने और drill down करने के लिए अच्छे हैं, लेकिन आखिर में अहम चीज़ data management practices और data/relationships/metrics को ठीक से समझकर उन्हें business insights से जोड़ने की क्षमता है
    भविष्य को लेकर उम्मीद है, लेकिन अब तक next-generation tools ने अपने वादे पूरे नहीं किए, इसलिए मैं आसानी से भरोसा नहीं करता
  • low-code tools में मैंने ऐसा बार-बार होते देखा है
    reasonable defaults और अपने ही पैर पर कुल्हाड़ी मारने वाली चीज़ में फर्क बस नजरिए का है
  • ठीक करने के बाद नंबर कम हुए तो क्या सबने हंगामा नहीं किया, यह जानने की उत्सुकता है
    बड़ी कंपनियों में देखा है कि अगर कोई subtle bug या design revenue को ज्यादा दिखा रहा हो, तो कोई भी उसे छेड़कर revenue drop की जिम्मेदारी नहीं लेना चाहता
    जैसे average resolution पर free plan का button fold के नीचे हो, state calculation गलत होने से discount लागू न हो, या किसी ने false छोड़ दिया हो जिससे signup तकनीकी रूप से जरूरी न होते हुए भी मांगा जा रहा हो
    नंबर कम होने पर लोग कहीं खुद को दोष न दें, क्या उन्हें भी ऐसा ही कुछ महसूस हुआ होगा—यह जानना चाहता हूं
  • यह सभी no-code solutions की common समस्या है
    complex logic flow लागू करते समय कठिन हिस्सा IDE में code type करना नहीं, बल्कि समस्या को model करना और effective algorithm design करना है
    ये tools non-technical users को इस वादे के साथ target करते हैं कि code लिखने की जरूरत नहीं होगी, लेकिन user फिर भी solution को engineering तरीके से design करने वाले complex हिस्से को नहीं समझता, और भटक जाता है या गलत नतीजे निकालता है
    complex business process को no-code tool से बढ़ाने की कोशिश आखिरकार बहुत trial and error के बाद दीवार से टकराती है, और अंत में असली engineer को सौंप दी जाती है
    लेकिन engineer को तब उस support के बिना काम करना पड़ता है जो असली programming language में code लिखते समय स्वाभाविक रूप से मिलता है
    visual flow builder में फंस जाने पर shared repository, सही version control, code review, automated tests, CI/CD लगभग नामुमकिन हो जाते हैं
  • दूसरे जगहों की तरह करना चाहिए। abstract relationships को views में compose करें, और self-service BI dashboards को उन views तक सीमित रखें जिनका meaning सही हो
    users मूल रूप से अपने नजरिए से ही देखते हैं, इसलिए उनके सोचने के तरीके से भी देखने का कोई alternative तरीका तैयार करना होगा
    मुझे एक product पता है जो education attendance को time-based तरीके से handle करता है, क्योंकि school, campus और date के हिसाब से timetable combinations अलग-अलग होते हैं और sports events, substitute work, combined class activities, 14-day rotating timetable जैसी flexibility चाहिए होती है
    लेकिन इसका मतलब यह नहीं कि उन complex timetables को class-based attendance या morning/afternoon attendance के synthesized views में बदला नहीं जा सकता

• यह मानना बेतुका है कि business users अपने सवाल, data model और dropdowns के बीच का संबंध सीख नहीं सकते या बहुत उतावले होते हैं
  मेरे अनुभव में तो वे सीखना चाहते हैं, लेकिन data modeler अक्सर domain को पर्याप्त नहीं समझता, इसलिए सवाल की nuance पकड़ नहीं पाता
  नतीजा यह होता है कि self-service को simplify करने के नाम पर nuance छिपा दी जाती है, जिससे answer पाने में समय बढ़ता है, या उसे पूरी तरह हटा दिया जाता है, जिससे inaccurate और misleading answers बनते हैं
  मुझे non-technical वाला euphemism भी पसंद नहीं। LLM, BI query generation tools और SQL के बीच काफी middle ground है; capability की दीवार को absolute घोषित करने की जरूरत नहीं

  • यह उस सलाह से भी जुड़ा है जो मैं programming में रुचि रखने वाले young लोगों को हमेशा देता हूं
    computer, programming और data analysis का expert बनना अच्छी बात है, लेकिन अगर संभव हो तो जिस domain में आप पढ़ते या काम करते हैं, उसे केंद्र में रखकर इन skills को secondary रूप में विकसित करें
    domain expert डेटा नहीं जानता और data expert domain नहीं जानता—इस समस्या का समाधान यह है कि दोनों एक ही व्यक्ति हों
  • मेरे career में best business/data outcomes तब आए जब SQL जानने वाला PM, simple extraction/scheduling tools, और BI developers के input या table design के आधार पर data engineering team द्वारा manage किया गया reasonable data model साथ में मौजूद था

• अभी organizational incompetence जैसे नए स्तर पर पहुंच गई लगती है
  spreadsheets की आलोचना करने वाला एक Dilbert comic था, और वही बात BI tools और AI tools पर भी लागू होती है
  कुछ इस तरह: “इस presentation की spreadsheet में जाहिर है errors और गलत जानकारी भरी हुई है। वैसे भी, जब तक यह management के पहले से लिए गए फैसले को reinforce नहीं करती, कोई इसे दोबारा देखने वाला नहीं, इसलिए फर्क नहीं पड़ता”
  वास्तविक दुनिया में भी broken reports और dashboards भरे पड़े हैं
  कुछ महीनों, कभी-कभी सालों तक बिल्कुल update नहीं होते, फिर भी किसी को पता नहीं चलता और वे processes, decisions और workflows में इस्तेमाल होते रहते हैं
  कभी data update नहीं होता, लेकिन date/time के आधार पर pivot होकर हर run में वही data फिर से rearrange होता है, इसलिए बहुत broken होने पर भी पता नहीं चलता
  कई बार तरह-तरह के formulas और “math” पूरी तरह गलत होते हैं और imaginary numbers output करते हैं

  • organizational incompetence कहना ठीक नहीं है। लोग incompetent नहीं हैं
    दुनिया जैसे-जैसे centralized EDW और ERP systems से दूर गई, data problems exponentially मुश्किल हो गईं, और investment का स्तर बस उसके साथ नहीं चल पाया

• पिछले 24 सालों से बिज़नेस users को data देता आ रहा हूँ, लेकिन चाहे query tool हो, MS Access हो, Power BI हो या Excel के data cubes, असल में इस्तेमाल करने वाले लोग गिने-चुने ही होते हैं
  शायद ये वही लोग होंगे जो 40 साल पहले भी terminal और printed reports से data खुरचकर analysis करते रहे होंगे
  फिर भी executives को key metrics dashboards पसंद आते हैं, और नए BI tools KPI dashboard बनाना और maintain करना कहीं आसान बना देते हैं

  • किसी कंपनी में ऐसे व्यक्ति को ढूँढना अच्छा लगता है जिसे खुद अंदाज़ा नहीं होता कि वह coding में कितना अच्छा है
    उसका job title “personal assistant” जैसा हो सकता है, लेकिन वह SharePoint forms, Access और Excel को hack करने जैसे अंदाज़ में इस्तेमाल करके कमाल की चीजें बना देता है
    उनकी चतुर क्षमता को पहचानकर उन्हें ज्यादा शक्तिशाली tools देना शानदार होता है। फिर वे कभी-कभी बेहतर नौकरी के लिए चले भी जाते हैं, और वह भी अच्छी बात है
  • शुरुआती computing के दिनों में ज्यादातर काम बड़े, shared mainframe पर होते थे
    कंप्यूटर इतने महंगे थे कि “computer department” कंपनी के भीतर एक अलग विभाग होता था; मसलन western division को computing resources चाहिए होते तो वह site पर installed mainframe रखने वाले computer department से contract करता था
    हमारा group नए और “सस्ते” minicomputers इस्तेमाल करने वाली छोटी और फुर्तीली internal analysis team था
    funding structure की वजह से user needs पर कहीं ज्यादा तेज़ प्रतिक्रिया दे पाना हमारा फायदा था
    एक दिन factory में चलते हुए मैंने देखा कि एक user हमारी बनाई green-striped report की पंक्तियाँ काटकर दूसरे कागज़ पर चिपका रहा था और copy कर रहा था
    वह report को किसी दूसरे criteria से sort कर रहा था, इसलिए मैंने कहा, “यह तो हम आपके लिए कर सकते हैं!” तो जवाब मिला, “सच में?”
    जिसे काम पूरा करना होता है, वह किसी न किसी तरह पूरा कर ही लेता है। internal customers को सेवा देने वाले computer systems group का लक्ष्य उस प्रक्रिया को जितना हो सके efficient बनाना है
    एक और व्यक्ति PC, tablet digitizer और AutoCAD का इस्तेमाल करके aircraft पर points record कर रहा था और radar profile बना रहा था
    यह CAD के मूल उपयोग से ज्यादा Jane's Combat Aircraft drawings से data capture करने का एक inventive तरीका था
  • जब systems integration software बनाने का काम मिलता है, तो कई बार सिर्फ existing dashboards को set up या expose कर देने से ही customers बहुत हैरान हो जाते हैं
    वे यकीन नहीं कर पाते कि वह data पहले से मौजूद था
    integration एक ज़रूरी business operation है, लेकिन आसानी से समझ आने वाला data stakeholders को सच में बहुत पसंद आता है। यह बहुत आसान value add है

• लेख में दिखाया गया traditional BI interface Metabase है, और अभी BI के लिए मौजूद interfaces में यह काफी अच्छा है
  Metabase में GUI द्वारा generated SQL देखा जा सकता है, और उस question को pure SQL में convert भी किया जा सकता है, इसलिए self-service से governance की ओर बढ़ने के लिए यह अच्छा है
  logic को modify और validate करना आसान है, और कम technical skill वाले लोगों के लिए skill बढ़ाने का रास्ता बनता है
  लेकिन लेख का मुख्य point सही है। professional data work करने वाले के नज़रिए से भी BI tools शायद ही कभी ज्यादा लोगों को data की सही समझ या उसके सही इस्तेमाल के लिए ज़रूरी skills देते हैं
  अगर data अच्छी तरह managed हो तो tool आसान हो जाता है और लोग समझ लेते हैं, लेकिन दुनिया complex है, इसलिए data भी complex हो जाता है
  data management cost साफ़ दिखाई देती है, जबकि benefits उतने साफ़ नहीं दिखते

• “self-service BI” को लेकर मैं भी मिलते-जुलते निष्कर्ष पर पहुँचा हूँ, लेकिन समाधान थोड़ा अलग है
  abstraction layer को और ऊपर ले जाकर, बहुत customizable dashboards बनाना बेहतर है, पर business users को SQL expose नहीं करना चाहिए
  उदाहरण के लिए ऐसा dashboard जिसमें 20 filters, breakdown dimensions, और “used assumptions” को control करने वाले 20 parameters हों
  “पिछले महीने Google ads की performance age group के हिसाब से देखनी है” जैसा question पहले से तय 3–4 dropdowns बदलने का काम बन जाता है
  यहाँ parameters महत्वपूर्ण हैं, क्योंकि सिर्फ validated controls expose होते हैं और arbitrary SQL की अनुमति नहीं होती
  बेशक ऐसे dashboards बनाना मुश्किल है और Looker, Tableau, Excel जैसी visualization expertise काफी चाहिए, लेकिन नतीजे में 70% questions self-service हो जाते हैं
  बाकी 30% को छोड़ देना बेहतर है, और business questions को data questions में translate करने के लिए किसी व्यक्ति की ज़रूरत होती है। यह people problem है

  • बार-बार आने वाले questions को पहचानकर उनके हिसाब से dashboard बना देना चाहिए
    फिर CFO हो या कोई और, किसी खास period का answer चाहिए हो तो वह dashboard खोलकर बस default parameters को थोड़ा adjust कर सकता है

• image में दिखाए गए Metabase का इस्तेमाल कर रहा हूँ, और कुल मिलाकर non-technical users भी सच में इसे इस्तेमाल करते हैं
  adoption में मदद करने वाली चीज़ थी “office hours” रखना और “किसी specific store या state की sales कैसे निकाली जाए” जैसे examples खुद दिखाना
  इससे हर problem, query या export solve नहीं हुआ, लेकिन पहले engineering तक आने वाली requests का बड़ा हिस्सा अब उस stage तक नहीं आता
  Metabase अच्छा होने की एक और वजह यह है कि इसे self-host किया जा सकता है और GSuite SSO इस्तेमाल किया जा सकता है

  • मेरे अनुभव में problem data query करने के साधन में नहीं, बल्कि data के अपने अजीब context में है
    key metric यह नहीं है कि “help requests कम हुईं, इसलिए users ज्यादा independent हैं”
    क्योंकि बहुत अधिक संभावना है कि वे users बिल्कुल गलत metrics निकालेंगे और interpret करेंगे
    मैंने बार-बार देखा है कि low-tech users जब data access करते हैं तो “यह तो सोचा था उससे आसान है” मान लेते हैं और खराब analysis का pyramid खड़ा करने लगते हैं
    सही analysis के लिए हमेशा context चाहिए
    उदाहरण के लिए recurring revenue में finance team delivery date को backfill करती है, इसलिए monthly revenue calculation में delivery date का इस्तेमाल नहीं करना चाहिए
    catalog price USD में store होता है, लेकिन असल में monthly_discount table के आधार पर exchange rate हर महीने adjust होता है
    पिछले साल के unsold inventory को दिखाने की convention की वजह से जिन items की purchase date null है, उन्हें sales report से हटाना चाहिए
    prices local currency में हैं, इसलिए exchange rate table से join किए बिना sales को sum नहीं करना चाहिए
  • Metabase अच्छा है
    मैंने इसे कंपनी के non-programmers के लिए set up किया है, और सच कहूँ तो वे मेरे बनाए dashboards देखने से आगे इसका बहुत कम इस्तेमाल करते हैं, लेकिन response अच्छा रहा
    यह सच में useful tool है

• यह बात हमेशा मज़ेदार लगती है कि senior managers मोटी तनख्वाह लेते हैं, फिर भी BI SQL queries नहीं चला पाते
  जबकि SQL मूल रूप से managers के लिए data को ज़्यादा आसानी से query करने के लिए बनाया गया था
  पुराने salesperson/manager के नज़रिए से, ऐसे लोगों के लिए बहुत सहानुभूति नहीं है

  • मैं एक CEO को जानता हूँ जो SQL “कर सकते” हैं, और कंपनी में SQL करने का दावा करने वाले ज़्यादातर लोगों से भी बेहतर करते हैं
    लेकिन वे खुद नहीं करते। क्योंकि उन्हें basic economics समझ आती है
    अगर वे किसी और के 3 दिन के काम को आधे दिन में कर भी सकते हों, तो वह आधा दिन उस काम से छिन जाता है जो सिर्फ CEO ही कर सकता है
    एक सक्षम CxO यह भी जानता है कि असली समय details को बिल्कुल सही करने में लगता है
    null handling की अजीब बातें, date handling, mismatched merges जैसी चीज़ों में, भले ही SQL “high-level” हो, भरोसेमंद जवाब पाने के लिए समय और focus चाहिए
    अगर कोई व्यक्ति इसी काम का specialist है, तो उसे वही काम सौंपना सही है

• मुझे लगता है BI dashboards बहुत simple queries के लिए अच्छे से काम कर सकते हैं
  अगर आप non-technical users से data joins चलाने को कहने तक पहुँच गए हैं, तो आप पहले ही बहुत गहराई में चले गए हैं, और उस समय सीधे SQL इस्तेमाल करना बेहतर है
  Joins कुछ लोगों को basic लग सकते हैं, लेकिन व्यक्तिगत रूप से मुझे भी वे कभी-कभी समझने में कठिन लगते हैं, और SQL से कम expressive dashboard UI में वे confusion पैदा करने वाला combination हैं
  आखिरकार यह एक trade-off है। इसे SQL की तुलना में non-technical users के लिए ज़्यादा accessible बनाया जा सकता है, लेकिन अनिवार्य रूप से यह SQL से कम powerful होगा
  फिर भी बीच की इस जगह में बहुत उपयोगिता है। असल में “BI” का बड़ा हिस्सा इस स्तर का होता है: “data के एक दर्जन columns हैं, इनमें से एक को दूसरे के against plot कर दो”
  लेखक SQL को एकमात्र “self-service” BI tool कहते हैं, लेकिन सच कहूँ तो मेरे हिसाब से वह Excel है
  कई BI tools, नए और इसलिए कम familiar interface के साथ Excel को फिर से बनाने जैसे हैं
  Excel से चिढ़ने वाला meme शायद इसलिए बना क्योंकि पहले लोगों ने Excel से complex काम करवाने की कोशिश की थी
  Complex data manipulation SQL से करें, और “इसे pie chart में दिखाओ” Excel से करें, तो शायद BI tool की सच में ज़रूरत ही न पड़े

  • मैं SQL और Excel के रिश्ते के बारे में लगभग यही बात कहने वाला था
    अगर underlying data sources साफ़ किए गए हों, transformed हों, और access control ठीक से लगा हो, तो सिर्फ VLOOKUP और pivots से भी हैरान करने वाली दूर तक जाया जा सकता है
    जब data sources एक से ज़्यादा हों, तो non-technical users को self-service का मौका देना हमेशा offline data mixing तक पहुँचता है
    और फिर सवाल आता है, “Data team, ‘आपका’ data ‘मेरे’ data से match क्यों नहीं कर रहा?”—जिसमें हमेशा यह मानकर चला जाता है कि उनकी तरफ़ वाला data सही है

• मुख्य समस्या यह है कि modern tools, Smalltalk workstations या Emacs जैसे classic desktops से अलग हैं
  वे environments पूरी तरह integrated होते थे, सब कुछ user के हाथ में होता था, और end-user programming की concept built-in थी
  org-mode में आप पल भर में अच्छे दिखने वाले slides बना सकते हैं, code snippets जल्दी लिखकर चला सकते हैं और results पा सकते हैं
  हालांकि dashboard के नज़रिए से इसकी सीमाएँ बड़ी हैं। Data को जल्दी plot किया जा सकता है, लेकिन result ज़्यादातर rough static image जैसा होता है, और PGF/TikZ से उसे शानदार बनाने में इतना समय लगता है कि वह व्यावहारिक विकल्प नहीं रह जाता, और फिर भी static ही रहता है
  Emacs अपने आप में सही tool है, लेकिन एक पुराने दौर का tool है
  Modern tools ज़्यादा flashy और तेज़ interactions देते हैं, लेकिन वे बहुत सीमित actions ही कर पाते हैं, inflexible UI में फँसे रहते हैं, और बाकी चीज़ों से integrated भी नहीं होते
  R, RStudio/quarto के साथ, शायद जल्दी और थोड़ा messy लेकिन अच्छे दिखने वाला content बनाने का सबसे तेज़ तरीका हो सकता है, लेकिन Emacs की flexibility से बहुत पीछे है
  अंततः classic paradigm और modern hardware performance के आधार पर पूरे modern software stack को फिर से लिखे बिना कोई समाधान दिखता नहीं है