कोणताही शासन निर्णय (GR) हे ठरवतो की योजनेचा लाभ कोणाला मिळणार, कोणाची बदली होणार किंवा परीक्षेत कोण उत्तीर्ण होणार. जेव्हा ही प्रक्रिया मानवी पातळीवर (हाताने) राबवली जाते, तेव्हा त्यात दोन त्रुटी नकळत शिरतात: एकाच वाक्याचा वेगवेगळ्या ठिकाणी वेगळा अर्थ लावला जातो, आणि जिथे धोरणात मुभाच नाही तिथे वैयक्तिक मर्जी (Discretion) वापरली जाते. एक चांगली सिस्टम या दोन्ही गोष्टी बंद करते. ती धोरण प्रत्येक व्यक्तीला, प्रत्येक वेळी एकाच काटेकोर पद्धतीने लागू करते आणि कोणताही निर्णय का घेतला गेला याचे स्पष्ट कारण दाखवते.
हे साध्य करणे हे कोडिंगपेक्षा धोरणाचे अचूक 'भाषेतर' करण्याचे काम आहे. त्यासाठी आम्ही वापरतो ती पद्धत खालीलप्रमाणे आहे.
धोरण जसेच्या तसे सॉफ्टवेअरमध्ये उतरवणे अवघड का असते?
शासकीय धोरणे माणसांनी वाचण्यासाठी लिहिलेली असतात. त्यामुळे त्यात “सर्वसाधारणपणे”, “शक्यतो” आणि “अपवादात्मक परिस्थितीत” असे लवचिक शब्द असतात. शिवाय मूळ निर्णयानंतर निघालेली परिपत्रके आणि ठरावीक तारखेपासून लागू होणाऱ्या सुधारणा यांवर ती अवलंबून असतात. माणूस आपली समज आणि आठवणीच्या जोरावर या मधल्या जागा भरून काढतो; पण सॉफ्टवेअर तसे करू शकत नाही.
पायरी 1: फक्त मुख्य शासन निर्णय नव्हे, तर सर्व संदर्भ एकत्र करा
सुरुवातीला सर्व कागदपत्रांचा पूर्ण संच गोळा करा: मूळ शासन निर्णय (GR), त्यानंतर निघालेले प्रत्येक सुधारणा परिपत्रक (Circular), क्षेत्रीय कार्यालयांना दिलेली स्पष्टीकरणे आणि नागरिक किंवा कर्मचारी प्रत्यक्ष भरतात ते अर्जाचे नमुने. यावरून एक 'रूल रजिस्टर' (नियम नोंदवही) तयार करा: प्रत्येक नियमासाठी एक स्वतंत्र ओळ, आणि तो नियम ज्या कलमातून आला आहे त्या कलमाचा क्रमांक व लागू होण्याची तारीख. जर एखाद्या नियमाला असा कोणताही अधिकृत संदर्भ नसेल, तर ती केवळ जुनी सवय असते — अधिकृत धोरण नाही; मग ती पद्धत पुढे ठेवायची की बंद करायची, याचा निर्णय विभागाने घ्यायचा असतो.
पायरी 2: प्रत्येक कलम 'अट आणि परिणाम' (If–Then) या स्वरूपात लिहा
शासन निर्णयातील प्रत्येक कलम *"जर या अटी पूर्ण झाल्या, तर हा परिणाम होईल" अशा स्पष्ट रचनेत मांडा. उदाहरणादाखल हे कलम पाहा: “एकाच ठिकाणी पाच वर्षे सेवा पूर्ण झालेला कर्मचारी बदलीसाठी पात्र असेल; मात्र सेवानिवृत्तीसाठी दोन वर्षांपेक्षा कमी कालावधी उरलेल्या कर्मचाऱ्यांना यातून वगळण्यात येईल.”*
हे कलम सॉफ्टवेअरचा नियम म्हणून लिहिताना अशा काही प्रश्नांची उत्तरे लागतात जी मूळ वाक्यात दिलेली नसतात:
- पाच वर्षांचा कालावधी नेमका कोणत्या तारखेपर्यंत मोजायचा: बदलीच्या आदेशाच्या तारखेपर्यंत, की एका निश्चित कट-ऑफ तारखेपर्यंत (Cut-off date)?
- दीर्घ रजा किंवा प्रतिनियुक्तीचा (Deputation) कालावधी या पाच वर्षांत धरायचा का?
- “सेवानिवृत्तीला दोन वर्षांपेक्षा कमी कालावधी” हा देखील त्याच कट-ऑफ तारखेपासून मोजायचा की आजच्या तारखेपासून?
या प्रत्येक प्रश्नाचे उत्तर त्या नियमाचा भाग बनते. अशा प्रकारे तयार झालेल्या अंतिम नियमात त्याचे इनपुट्स (हजर झाल्याची तारीख, जन्मतारीख, कट-ऑफ तारीख), त्याचा निकाल (पात्र किंवा अपात्र) आणि मूळ शासन निर्णयातील कलम स्पष्टपणे नोंदवलेले असते.
पायरी 3: कोणतीही संदिग्धता धोरण ठरवणाऱ्या अधिकाऱ्याकडून लेखी स्वरूपात सोडवून घ्या
पायरी 2 मध्ये उपस्थित झालेल्या प्रश्नांची उत्तरे सॉफ्टवेअर प्रोग्रॅमरने स्वतःच्या मनाने ठरवायची नसतात. त्यासाठी एक 'क्वेश्चन लॉग' (प्रश्न नोंदवही) ठेवा: त्यामध्ये प्रत्येक शंका, तिचे संभाव्य पर्याय आणि संबंधित धोरणाची जबाबदारी असलेल्या वरिष्ठ अधिकाऱ्याने तारखेसह दिलेला निर्णय नोंदवा. अनेक शासकीय विभागांना हा लॉग स्वतःसाठीच खूप मोलाचा वाटतो, कारण मूळ शासन निर्णयात नेमके कुठे शुद्धिपत्रक किंवा स्पष्टीकरण काढण्याची गरज आहे, हे यातून लगेच लक्षात येते.
पायरी 4: सिस्टम सुरू (Go-live) करण्यापूर्वी खऱ्या केसेसवर नियम तपासून पाहा
ज्या अनुभवी अधिकाऱ्यांना धोरणाची खडान्खडा माहिती आहे, त्यांनाच टेस्ट केसेस तयार करायला सांगा: प्रत्यक्ष परिस्थितीतील अर्जदार किंवा कर्मचाऱ्यांची उदाहरणे आणि नियमानुसार प्रत्येकाचा काय निकाल यायला हवा याची यादी. यात मुद्दाम गुंतागुंतीची प्रकरणे (Edge cases) समाविष्ट करा — जसे की नेमक्या कट-ऑफ तारखेलाच रुजू झालेला कर्मचारी, प्रतिनियुक्तीवर असलेला कर्मचारी किंवा पुढच्याच महिन्यात रिटायर होणारा कर्मचारी. जेव्हा सिस्टम या प्रत्येक प्रकरणात अधिकाऱ्यांना अपेक्षित असलेलाच अचूक निकाल देते आणि तो निकाल कोणत्या कलमानुसार आला हे त्यांच्याच परिचित भाषेत दाखवते, तेव्हाच सिस्टम कामासाठी सज्ज झाली असे समजावे.
पायरी 5: नियम कोडमध्ये न गाडता, लागू होण्याच्या तारखेसह डेटा म्हणून ठेवा
शासकीय धोरणे काळानुसार बदलतात. जर एखादा नियम प्रोग्रॅमच्या कोडमध्ये पक्का लिहून ठेवला (Hard-code केला), तर प्रत्येक छोट्या बदलासाठी डेव्हलपर बोलवावा लागतो आणि नवीन सॉफ्टवेअर रिलीज करावे लागते. म्हणूनच आम्ही नियम आणि त्यांच्या मर्यादा (उदा. वरील 5 वर्षे किंवा 2 वर्षे) या 'सुरुवातीची तारीख' आणि 'शेवटची तारीख' असलेल्या कॉन्फिगर करण्यायोग्य डेटाच्या स्वरूपात ठेवतो. जेव्हा नवीन परिपत्रक येते, तेव्हा विभाग स्वतःच नवीन आकडा आणि तारीख अपडेट करू शकतो. यामुळे जुन्या प्रकरणांना जुना नियम आणि नवीन प्रकरणांना नवीन नियम आपोआप लागू होतो, आणि भूतकाळातील कोणताही निर्णय त्या दिवशी लागू असलेल्या नियमाच्या आधारे कधीही सिद्ध करता येतो.
यामुळे अधिकारी आणि नागरिकांसाठी काय बदल घडतो?
- प्रत्येक निर्णयासोबत त्याचे कारण स्पष्ट दिसते: नेमका कोणता नियम लागू झाला आणि तो कोणत्या शासन निर्णयातील कोणत्या कलमातून आला.
- अर्जदारांना आपल्या अर्जाची स्थिती (Status) आणि त्याचे कारण स्वतःच पाहता येते; उत्तरासाठी कार्यालयाच्या चकरा माराव्या लागत नाहीत.
- विशेष अधिकारांचा वापर पारदर्शक होतो. जिथे धोरणानेच अपवादात्मक सवलतीची परवानगी दिली आहे, तिथे ती सवलत कोणत्या अधिकाऱ्याने आणि कोणत्या कारणास्तव मंजूर केली याची स्पष्ट नोंद सिस्टममध्ये राहते — त्यामुळे अपवाद लपून राहत नाहीत, तर अधिकृतरीत्या नोंदवले जातात.
- शासकीय ऑडिट अत्यंत सोपे होते, कारण प्रत्येक कृतीचा ऑडिट ट्रेल सिस्टमच्या रचनेतूनच आपोआप तयार झालेला असतो.
एक छोटी पडताळणी यादी (Checklist)
- आपल्याकडे फक्त मूळ शासन निर्णयच नाही, तर त्यानंतरची सर्व परिपत्रके आणि स्पष्टीकरणे जमा आहेत का?
- रूल रजिस्टरमधील प्रत्येक नियमाला अधिकृत कलम आणि लागू होण्याची तारीख जोडलेली आहे का?
- क्वेश्चन लॉगमधील प्रत्येक संदिग्ध प्रश्नावर जबाबदार धोरण-अधिकाऱ्याने लेखी मान्यता दिली आहे का?
- अधिकाऱ्यांनी गुंतागुंतीच्या प्रकरणांसह सर्व टेस्ट केसेस तयार केल्या आहेत का, आणि सिस्टम त्या सर्व केसेसमध्ये अचूक निकाल देते का?
- नवीन सॉफ्टवेअर रिलीज न करता विभागाला स्वतःहून एखादी मर्यादा किंवा कट-ऑफ तारीख बदलता येते का?
जर तुम्ही एखादी शासकीय योजना, बदली प्रक्रिया किंवा विद्यापीठाचा परीक्षा अध्यादेश (Examination Ordinance) डिजिटल करण्याच्या तयारीत असाल, तर कोणत्याही व्हेंडरने कोडिंग सुरू करण्यापूर्वी आम्ही तुम्हाला 'रूल रजिस्टर' आणि 'टेस्ट केसेस' तयार करून देऊ शकतो — किंवा संपूर्ण प्लॅटफॉर्म स्वतः डिझाइन करून उभारू शकतो.