कोई भी शासनादेश (GR) यह तय करता है कि योजना का लाभ किसे मिलेगा, किसका तबादला होगा या परीक्षा में कौन उत्तीर्ण होगा। जब अधिकारी इसे मैनुअल तरीके से (हाथ से) लागू करते हैं, तो दो कमियाँ अनजाने में आ जाती हैं: एक ही वाक्य के अलग-अलग अर्थ निकाले जाते हैं, और जहाँ नीति में कोई गुंजाइश नहीं थी वहाँ भी व्यक्तिगत मर्ज़ी (Discretion) चलने लगती है। एक सुगठित सिस्टम इन दोनों कमियों को ख़त्म कर देता है। वह नीति को हर व्यक्ति पर, हर बार एक ही तरह लागू करता है और हर फ़ैसले के पीछे का कारण स्पष्ट दिखाता है।
यहाँ तक पहुँचना कोडिंग से ज़्यादा नीति के सटीक 'रूपांतरण' का काम है। इसके लिए हम जो तरीका अपनाते हैं, वह नीचे दिया गया है।
नीति को सीधे सॉफ़्टवेयर में उतारना कठिन क्यों होता है?
सरकारी नीतियाँ इंसानों के पढ़ने के लिए लिखी जाती हैं। उनमें “सामान्यतः”, “यथासंभव” और “अपवादात्मक परिस्थितियों में” जैसे लचीले शब्द होते हैं। इसके अलावा वे बाद में जारी हुए उन परिपत्रों (Circulars) पर निर्भर होती हैं जो नए अपवाद जोड़ते हैं, और उन संशोधनों पर जो किसी ख़ास तारीख़ से लागू होते हैं। इंसान इन ख़ाली जगहों को अपनी समझ और याददाश्त से भर लेता है, लेकिन सॉफ़्टवेयर ऐसा नहीं कर सकता।
चरण 1: सिर्फ़ मुख्य शासनादेश नहीं, बल्कि हर संबंधित दस्तावेज़ जुटाइए
पूरे दस्तावेज़ों के सेट से शुरुआत कीजिए: मुख्य शासनादेश (GR), उसके बाद जारी हुआ हर संशोधन परिपत्र, फ़ील्ड कार्यालयों को भेजे गए स्पष्टीकरण, और वे फ़ॉर्म जिन्हें लोग वास्तव में भरते हैं। इसके बाद एक 'रूल रजिस्टर' (नियम रजिस्टर) बनाइए: हर नियम के लिए एक पंक्ति, जो उस सटीक धारा से जुड़ी हो जहाँ से वह नियम आया है, और उस तारीख़ से जिस दिन से वह लागू होता है। अगर किसी प्रचलित नियम का कोई लिखित सरकारी स्रोत नहीं मिलता, तो वह नीति नहीं बल्कि किसी की पुरानी आदत है — और विभाग को तय करना चाहिए कि उसे आगे रखना है या हटाना है।
चरण 2: हर धारा को 'शर्त और परिणाम' (If–Then) के रूप में दोबारा लिखिए
शासनादेश की हर धारा को इस रूप में लिखिए: "यदि ये शर्तें पूरी होती हैं, तो यह परिणाम होगा।" उदाहरण के लिए एक धारा देखिए: “जिस कर्मचारी ने किसी पदस्थापना (Posting) पर पाँच वर्ष पूरे कर लिए हैं, वह तबादले के लिए पात्र है — सिवाय उन कर्मचारियों के जिनकी सेवानिवृत्ति (Retirement) में दो वर्ष से कम समय बचा है।”
इसे सॉफ़्टवेयर का नियम बनाने के लिए कुछ ऐसे सवालों के स्पष्ट जवाब चाहिए जो इस वाक्य में नहीं लिखे हैं:
- पाँच वर्ष किस तारीख़ तक गिने जाएँगे: तबादला आदेश निकलने की तारीख़ तक, या किसी तय कट-ऑफ़ तारीख़ (Cut-off date) तक?
- क्या लंबी छुट्टी या प्रतिनियुक्ति (Deputation) की अवधि इन पाँच वर्षों में गिनी जाएगी?
- “सेवानिवृत्ति में दो वर्ष से कम” की गणना भी उसी कट-ऑफ़ तारीख़ से होगी या आज की तारीख़ से?
इन सवालों का हर जवाब नियम का हिस्सा बन जाता है। इस तरह तैयार हुए अंतिम नियम में उसके इनपुट (वर्तमान पदस्थापना पर ज्वाइन करने की तारीख़, जन्मतिथि, कट-ऑफ़ तारीख़), उसका नतीजा (पात्र या अपात्र) और उसकी मूल धारा — तीनों बातें बिल्कुल साफ़ दर्ज होती हैं।
चरण 3: हर अस्पष्टता को नीति के ज़िम्मेदार अधिकारी के साथ लिखित में सुलझाइए
चरण 2 में उठे सवालों का जवाब किसी सॉफ़्टवेयर प्रोग्रामर को अपने मन से नहीं तय करना चाहिए। इसके लिए एक 'क्वेश्चन लॉग' (प्रश्न पंजिका) बनाइए: जिसमें हर अस्पष्टता, उसके संभावित विकल्प और नीति के ज़िम्मेदार अधिकारी का लिखित निर्णय तारीख़ के साथ दर्ज हो। कई विभागों को यह लॉग अपने-आप में बहुत उपयोगी लगता है, क्योंकि इससे तुरंत पता चल जाता है कि मूल शासनादेश में कहाँ स्पष्टीकरण परिपत्र जारी करने की ज़रूरत है।
चरण 4: गो-लाइव से पहले असली मामलों (Real Cases) पर नियमों को परखिए
नीति को गहराई से जानने वाले अनुभवी अधिकारियों से टेस्ट केस लिखवाइए: वास्तविक जैसे आवेदकों या कर्मचारियों के उदाहरण और नियम के अनुसार हर एक का अपेक्षित परिणाम। इसमें पेचीदा मामले (Edge cases) ज़रूर शामिल कीजिए — जैसे वह कर्मचारी जिसने ठीक कट-ऑफ़ तारीख़ को ज्वाइन किया हो, जो प्रतिनियुक्ति पर हो, या जो अगले ही महीने रिटायर होने वाला हो। सिस्टम तभी पूरी तरह तैयार माना जाएगा जब वह हर मामले में अधिकारियों के अपेक्षित परिणाम दे और हर फैसले का कारण उन्हीं के परिचित शब्दों में बताए।
चरण 5: नियमों को कोड में दबाने के बजाय लागू होने की तारीख़ के साथ डेटा के रूप में रखिए
सरकारी नीतियाँ समय के साथ बदलती हैं। अगर कोई नियम प्रोग्राम के कोड के भीतर हार्ड-कोड कर दिया जाए, तो हर छोटे बदलाव के लिए डेवलपर और नई सॉफ़्टवेयर रिलीज़ की ज़रूरत पड़ती है। इसलिए हम नियमों और उनकी सीमाओं (जैसे ऊपर दिए गए 5 वर्ष या 2 वर्ष) को 'प्रारंभ तिथि' और 'समाप्ति तिथि' वाले कॉन्फ़िगरेशन डेटा के रूप में रखते हैं। जब भी कोई नया परिपत्र आता है, विभाग स्वयं नई संख्या और तारीख़ अपडेट कर देता है। इससे सिस्टम पुराने मामलों पर पुराना नियम और नए मामलों पर नया नियम लागू करता है, और पिछले हर फ़ैसले को उस दिन लागू रहे नियम के आधार पर कभी भी सत्यापित किया जा सकता है।
इससे अधिकारियों और नागरिकों के लिए क्या बदलता है?
- हर फ़ैसले के साथ उसका स्पष्ट कारण दिखता है: कौन-सा नियम लागू हुआ और वह किस शासनादेश की किस धारा से आया है।
- आवेदक अपने आवेदन की स्थिति (Status) और उसका कारण ख़ुद देख सकते हैं; उन्हें जवाब के लिए दफ़्तरों के चक्कर नहीं लगाने पड़ते।
- विशेष छूट पूरी तरह पारदर्शी हो जाती है। जहाँ नीति वास्तव में अपवाद की अनुमति देती है, वहाँ सिस्टम यह दर्ज करता है कि वह छूट किस अधिकारी ने और किस कारण से दी — ताकि अपवाद छिपे न रहें, बल्कि विधिवत मंज़ूर किए जाएँ।
- सरकारी ऑडिट बहुत आसान हो जाते हैं, क्योंकि सिस्टम के डिज़ाइन से ही पूरा ऑडिट ट्रेल अपने-आप तैयार होता रहता है।
एक संक्षिप्त जाँच-सूची (Checklist)
- क्या हमारे पास सिर्फ़ मुख्य शासनादेश ही नहीं, बल्कि बाद के सभी परिपत्र और स्पष्टीकरण भी मौजूद हैं?
- क्या रूल रजिस्टर का हर नियम किसी स्पष्ट धारा और लागू होने की तारीख़ से जुड़ा है?
- क्या क्वेश्चन लॉग की हर अस्पष्टता पर नीति के ज़िम्मेदार अधिकारी की लिखित मंज़ूरी ले ली गई है?
- क्या अधिकारियों ने पेचीदा मामलों सहित सभी टेस्ट केस लिखे हैं, और क्या सिस्टम उन सभी में सही परिणाम दे रहा है?
- क्या विभाग बिना किसी नई सॉफ़्टवेयर रिलीज़ के कोई सीमा या कट-ऑफ़ तारीख़ बदल सकता है?
यदि आप किसी सरकारी योजना, तबादला प्रक्रिया या विश्वविद्यालय के परीक्षा अध्यादेश (Examination Ordinance) को डिजिटल बनाने की तैयारी कर रहे हैं, तो किसी भी वेंडर के कोड लिखने से पहले हम आपके लिए 'रूल रजिस्टर' और 'टेस्ट केस' तैयार कर सकते हैं — या पूरा प्लेटफ़ॉर्म शुरू से डिज़ाइन और डेवलप कर सकते हैं।