सार्वजनिक क्षेत्र में SAP इम्प्लीमेंटेशन: अनुपालन और जोखिम

सार्वजनिक क्षेत्र के SAP में अनुपालन को पहली डिज़ाइन वर्कशॉप से ही सिस्टम में कॉन्फ़िगर करना पड़ता है। फ़ंड अकाउंटिंग और बजट चेक Public Sector Management (PSM) में आते हैं। सेग्रीगेशन ऑफ़ ड्यूटीज़ रोल डिज़ाइन में आती है। प्रोक्योरमेंट की सीमाएँ और टेंडर रिकॉर्ड वर्कफ़्लो में आते हैं। डेटा रेज़िडेंसी का फ़ैसला कॉन्ट्रैक्ट पर दस्तख़त से पहले हो जाना चाहिए। यह गाइड सरकारी एजेंसियों और सरकार से जुड़ी संस्थाओं के CFO, CIO और प्रोग्राम डायरेक्टर के लिए है। इसमें वे कंट्रोल हैं जो ऑडिट की आपत्तियों को रोकते हैं, 2026 के डिप्लॉयमेंट विकल्प और ज़रूरी टीम। नीचे दी गई कंट्रोल टेबल और कॉन्ट्रैक्ट से पहले की चेकलिस्ट का इस्तेमाल कीजिए।

सरकारों के पास उन अनुपालन विफलताओं के लिए कोई गुंजाइश नहीं होती जो ऑडिट में जाकर सामने आती हैं। मैं 10 साल से ज़्यादा से सार्वजनिक क्षेत्र के SAP प्रोजेक्ट पर काम कर रहा हूँ, और “अनुपालन दस्तावेज़ में है” और “अनुपालन सिस्टम में लागू है” के बीच की खाई go-live के बाद पाटने के लिए सबसे महँगी खाई है।

मैंने देखा है कि जब अनुपालन शुरू से बनाया जाता है तो क्या होता है: एजेंसियों का समय बचता है, ऑडिट की विफलताएँ रुकती हैं और जवाबदेही साफ़ रहती है। मैंने ऐसे प्रोजेक्ट पर भी काम किया है जहाँ टीमों ने यह सोचकर अनुपालन जाँचें छोड़ दीं कि बाद में सँभाल लेंगे। महीनों बाद सुरक्षा की कमियों और क़ानूनी उल्लंघनों ने उन्हें पीछे लौटने पर मजबूर किया, और इसकी क़ीमत मिलियनों में चुकानी पड़ी।

हाल का सबसे अच्छी तरह दर्ज उदाहरण SAP का है ही नहीं। Birmingham City Council ने 2018 में अपने Oracle Fusion रिप्लेसमेंट के लिए £20 मिलियन से थोड़ा कम बजट रखा था। बाहरी ऑडिटर की 2025 की public interest report में पाया गया कि सिस्टम और उसे ठीक करने का काम मूल बजट से कम से कम £90 मिलियन ज़्यादा में पड़ेगा। रिकवरी के 2026 तक चलने की उम्मीद थी। कारण पहले से अनुमान लगाने लायक़ थे। सार्वजनिक क्षेत्र की ज़्यादातर ERP विफलताएँ ऐसी ही होती हैं।

जो कंसल्टेंट निजी क्षेत्र की धारणाएँ साथ लाते हैं, वे ऐसी समस्याएँ पैदा करते हैं जो देर से सामने आती हैं, जब उन्हें ठीक करना महँगा होता है।

प्रोक्योरमेंट में ज़्यादा समय लगता है। वेंडर अप्रूवल में नियामकीय जाँचें होती हैं जो व्यावसायिक प्रोक्योरमेंट में नहीं होतीं। जिस सप्लायर को जल्दी मंज़ूरी मिल गई, वह बाद में सुरक्षा समीक्षा में फ़ेल हो सकता है, और वह प्रोजेक्ट की समस्या बन जाता है। प्रोक्योरमेंट की योजना नियामकीय चक्र के हिसाब से बनाइए, व्यावसायिक चक्र के हिसाब से नहीं।

बजट ढाँचे ज़्यादा जटिल हैं। फ़ंड अकाउंटिंग, ग्रांट और बहु-वर्षीय प्रतिबद्धताओं के लिए PSM कॉन्फ़िगरेशन चाहिए, जो स्टैंडर्ड इम्प्लीमेंटेशन में शामिल नहीं होता। टैक्स और राजस्व एजेंसियों को नागरिकों से जुड़े राजस्व के लिए Public Sector Collection and Disbursement (PSCD) भी चाहिए। इनमें से कोई भी ग़लत हुआ तो वित्तीय रिपोर्टें ऑडिट तक सच्चाई नहीं दिखातीं।

अप्रूवल चक्र क़ानून से तय होते हैं। सरकारी अप्रूवल को व्यावसायिक वर्कफ़्लो की तरह सरल नहीं किया जा सकता। उनके हिसाब से शुरू से डिज़ाइन कीजिए। क़ानूनी ज़रूरतों को नज़रअंदाज़ करने वाले वर्कफ़्लो को लोग बायपास कर देते हैं, और वे जुगाड़ ऑडिट ट्रेल को नष्ट कर देते हैं।

डेटा ज़्यादा संवेदनशील है। नागरिकों का डेटा, टैक्स रिकॉर्ड और कर्मचारियों की जानकारी पर संप्रभुता के दायित्व लागू होते हैं। डेटा कहाँ रहता है, यह ज़्यादातर क्षेत्राधिकारों में क़ानूनी ज़रूरत है, तकनीकी पसंद नहीं।

वित्तीय अनुपालन

हर आम विफलता के लिए SAP में एक ख़ास कंट्रोल है:

जोखिम	यह कैसा दिखता है	SAP कंट्रोल
बिना ट्रैकिंग का विभागीय ख़र्च	महीने के अंत तक दिखे बिना बजट से ज़्यादा ख़र्च	PSM में फ़ंड मैनेजमेंट और बजट उपलब्धता नियंत्रण
ऑडिट ट्रेल का अभाव	पूरे अप्रूवल इतिहास के बिना ट्रांज़ैक्शन	document flow कॉन्फ़िगरेशन और अनिवार्य अप्रूवल स्टेप
कंट्रोल का मैन्युअल ओवरराइड	प्रोसेसिंग तेज़ करने के लिए यूज़र अप्रूवल को बायपास करते हैं	ऑथराइज़ेशन डिज़ाइन और सेग्रीगेशन ऑफ़ ड्यूटीज़ का पालन
बिना सत्यापन के भुगतान	गुड्स रिसीट या अप्रूवल से पहले इनवॉइस का भुगतान	MM और FI में लागू थ्री-वे मैच
टैक्स सेट-अप में ग़लती	सार्वजनिक संस्था के टैक्स नियम सिस्टम में नहीं हैं	टैक्स ज्यूरिस्डिक्शन सेट-अप और रेट कॉन्फ़िगरेशन
सेग्रीगेशन ऑफ़ ड्यूटीज़ में कमियाँ	एक ही व्यक्ति भुगतान बनाता और अप्रूव करता है	रोल डिज़ाइन रिव्यू और सेग्रीगेशन ऑफ़ ड्यूटीज़ मैट्रिक्स

सेग्रीगेशन ऑफ़ ड्यूटीज़ को लगातार कम आँका जाता है। अगर एक ही व्यक्ति वेंडर बना सकता है, परचेज़ ऑर्डर जारी कर सकता है, माल प्राप्त कर सकता है और भुगतान अप्रूव कर सकता है, तो काग़ज़ पर कितने भी नियम हों, सिस्टम में कोई असरदार कंट्रोल नहीं है।

1. 01वेंडर बनाएँपहले नियामकीय जाँचों से मंज़ूरी
2. 02परचेज़ ऑर्डर जारी करेंPSM में बजट उपलब्धता नियंत्रण ओवरस्पेंड रोकता है
3. 03माल प्राप्त करेंMM में ऑर्डर के सामने दर्ज
4. 04इनवॉइस मैच करेंMM और FI में थ्री-वे मैच लागू
5. 05भुगतान अप्रूव करेंकिसी दूसरे व्यक्ति का अनिवार्य अप्रूवल

भुगतान हुआ, पूरा अप्रूवल इतिहास document flow में

प्रोक्योरमेंट अनुपालन

सार्वजनिक प्रोक्योरमेंट में असफलता के तरीक़े ज़्यादातर टीमों की उम्मीद से ज़्यादा हैं। ये पाँच बार-बार सामने आते हैं।

1. वेंडर अप्रूवल में जल्दबाज़ी। शेड्यूल तंग लगा, इसलिए एक सप्लायर को एक दिन में मंज़ूरी दे दी गई। बाद में वही वेंडर उस सुरक्षा ज़रूरत पर फ़ेल हुआ जो शुरू से कॉन्ट्रैक्ट में थी। कमी प्रोसेस डिज़ाइन में थी, सिस्टम में नहीं।
2. कॉन्ट्रैक्ट बदलावों का ट्रैक न रखना। कोई एक सर्विस लाइन जोड़ देता है और बजट ओनर जल्दी अप्रूव कर देते हैं। छह महीने बाद कोई नहीं बता सकता कि स्कोप कब बदला या किसने अधिकृत किया। इसके बाद ऑडिट की आपत्ति आती है।
3. बजट मंज़ूरी से पहले ख़र्च। टीमें यह मानकर ख़र्च कमिट कर देती हैं कि फ़ंड आ जाएगा। फ़ाइनेंस इनवॉइस रिजेक्ट कर देता है, वेंडर काम रोक देता है और सफ़ाइयाँ शुरू हो जाती हैं।
4. टेंडर रिकॉर्ड अधूरे। ऑडिटर बिड मूल्यांकन और चयन निर्णयों का पूरा ट्रेल चाहते हैं। अगर वह SAP के बजाय ईमेल में है, तो वे पूछेंगे क्यों। मैंने एक बार एक पूरा हफ़्ता छूटे हुए टेंडर सबूत दोबारा बनाने में लगाया, जो इम्प्लीमेंटेशन के बीच समय लगाने की जगह नहीं है।
5. सीमाओं को बायपास करना। यूज़र अप्रूवल लिमिट के इर्द-गिर्द रास्ते निकाल लेते हैं, जो समीक्षा ट्रिगर करने के लिए बनी होती हैं। हर जुगाड़ एक दिन बचाता है और असली अनुपालन जोखिम खड़ा करता है।

यह सरकारी प्रोक्योरमेंट सिस्टम में कैसे चलता है, इसके लिए UAE के सार्वजनिक क्षेत्र में SAP Ariba पर मेरे नोट्स देखिए।

डेटा रेज़िडेंसी और डेटा सुरक्षा

क्लाउड प्रोवाइडर डेटा को अलग-अलग क्षेत्रों में होस्ट करते हैं। जब तक होस्टिंग की पुष्टि कॉन्ट्रैक्ट और तकनीक, दोनों स्तर पर न हो, सरकारी डेटा किसी को पता चले बिना देश के बाहर पहुँच सकता है, और लीगल टीम को सबसे बुरे समय पर पता चलता है। बार-बार दिखने वाली कमियाँ ये हैं: होस्टिंग की जगह साफ़ न होना, एन्क्रिप्शन का आंशिक या ग़लत कॉन्फ़िगर होना, सुविधा के लिए एडमिन एक्सेस बड़े पैमाने पर दे देना, रिटेंशन नियमों का भटक जाना, और बैकअप पर लाइव सिस्टम से कम सख़्त नियंत्रण। यह मान लेना कि कोई और इसे सँभाल रहा है, संप्रभुता की समस्याओं की जड़ है। एक ओनर तय कीजिए, डिज़ाइन में इसका नक़्शा बनाइए और go-live से पहले इसका परीक्षण कीजिए।

ये वे क्षेत्र हैं जहाँ सार्वजनिक क्षेत्र का स्कोप व्यावसायिक प्रोग्राम से अलग होता है:

चुनौती का क्षेत्र	इसके लिए क्या चाहिए
जटिल बजट ढाँचे	फ़ंड अकाउंटिंग, ग्रांट और बहु-वर्षीय बजट नियंत्रण के लिए PSM
टैक्स और राजस्व संग्रह	नागरिकों से जुड़ी प्राप्य राशि, रिफ़ंड और वसूली के लिए PSCD
प्रोक्योरमेंट विनियमन	तयशुदा अप्रूवल चेन और ट्रेस करने योग्य प्रोक्योरमेंट रिकॉर्ड के लिए वर्कफ़्लो
लेगेसी इंटीग्रेशन	कस्टम-निर्मित प्लेटफ़ॉर्म से माइग्रेशन और भरोसेमंद इंटरफ़ेस
यूनियन और पेरोल नियम	सामूहिक समझौतों और यूनियन-विशिष्ट वेतन को दर्शाने वाला पेरोल
नागरिकों को दी जाने वाली सेवाएँ	केस मैनेजमेंट के साथ इंटीग्रेशन और नागरिक डेटा गोपनीयता कंट्रोल
बहु-एजेंसी प्रक्रियाएँ	विभागों में साझा वित्तीय ढाँचों के लिए SAP Central Finance
ऑडिट दस्तावेज़ीकरण	आर्काइविंग, अप्रूवल इतिहास और टेंडर रिकॉर्ड जिन्हें ऑडिटर निकाल सकें

सरकारी प्रोजेक्ट सॉफ़्टवेयर की वजह से कम ही फ़ेल होते हैं। वे तब फ़ेल होते हैं जब स्कोप संगठन की बदलाव सँभालने की क्षमता से आगे निकल जाता है, या जब अनुपालन की ज़रूरतें go-live के बाद पता चलती हैं।

चरणबद्ध रोलआउट किसी एक go-live का जोखिम घटाता है। पहले फ़ाइनेंस और प्रोक्योरमेंट, क्योंकि उन पर अनुपालन का सबसे ज़्यादा भार है। फिर पेरोल और HR, जब कोर फ़ाइनेंशियल स्थिर हो जाएँ। उसके बाद नागरिकों को दी जाने वाली सेवाएँ। पूरा go-live तभी चलता है जब योजना पूरी हो, कॉन्फ़िगरेशन से पहले अनुपालन ज़रूरतें दर्ज हो चुकी हों, आंतरिक टीम के पास क्षमता हो और डेटा साफ़ हो। सरकार में यह मेल दुर्लभ है। जब यह न हो, तो चरणबद्ध रास्ता सुरक्षित है। मेरी इम्प्लीमेंटेशन रणनीति गाइड पैटर्न की तुलना ज़्यादा विस्तार से करती है।

डेटा रेज़िडेंसी तय करती है कि डिप्लॉयमेंट मॉडल क्या होगा

सार्वजनिक क्षेत्र के ख़रीदारों के लिए रोलआउट और माइग्रेशन रणनीति डिप्लॉयमेंट के फ़ैसले के बाद आती है, और वह फ़ैसला डेटा रेज़िडेंसी से तय होता है।

अगर नागरिकों का डेटा देश के भीतर रहना ज़रूरी है और SAP सही ऑथराइज़ेशन के साथ देश के भीतर सत्यापित होस्टिंग दिखा सकता है, तो S/4HANA Cloud Private Edition पर RISE with SAP सबसे मज़बूत विकल्प है। यह इन्फ्रास्ट्रक्चर SAP को सौंप देता है, जिससे उन एजेंसियों को मदद मिलती है जिनकी इंटरनल Basis टीम छोटी है। अगर देश के भीतर होस्टिंग दिखाई नहीं जा सकती, तो ऑपरेशनल बोझ के बावजूद on-premise या सॉवरेन क्लाउड पार्टनर ज़्यादा सुरक्षित जवाब बना रहता है।

Public Edition में अब सार्वजनिक क्षेत्र का स्कोप है

SAP अब S/4HANA Cloud Public Edition में सार्वजनिक क्षेत्र के फ़ंक्शन देता है। इसका PSM स्कोप बंडल बजट मैनेजमेंट, ग्रांट, अर्मार्क्ड फ़ंड और उपलब्धता नियंत्रण कवर करता है, और SAP 2025 और 2026 में इसे देश-दर-देश जारी कर रहा है। जो एजेंसी स्टैंडर्ड प्रोसेस के साथ ग्रीनफ़ील्ड शुरू कर रही है, उसके लिए यह बहुत-सा बुनियादी काम हटा देता है। यह क्षेत्राधिकार-विशिष्ट डिज़ाइन नहीं हटाता: चार्ट ऑफ़ अकाउंट्स, टैक्स ढाँचे और बजट नियम। SAP का अपना मार्गदर्शन है कि यह देश के हिसाब से स्थानीय GAAP देता है और अलग से कोई IPSAS अकाउंटिंग सिद्धांत नहीं देता, इसलिए अपनी IPSAS मैपिंग की योजना डिज़ाइन का हिस्सा बनाइए।

RISE क्या कवर करता है और क्या नहीं

सार्वजनिक क्षेत्र में RISE की सबसे आम ग़लती यह मान लेना है कि चूँकि SAP इन्फ्रास्ट्रक्चर चलाता है, इसलिए वह अनुपालन की सारी समस्याएँ पकड़ लेगा। SAP इन्फ्रास्ट्रक्चर अनुपालन कवर करता है: होस्टिंग, एन्क्रिप्शन, प्लेटफ़ॉर्म उपलब्धता। वह सेग्रीगेशन ऑफ़ ड्यूटीज़, ख़राब डिज़ाइन वाले इंटरफ़ेस या टेंडर दस्तावेज़ीकरण की कमियाँ कवर नहीं करता। इनके मालिक अब भी एजेंसी और उसका पार्टनर हैं।

सरकार में कस्टमाइज़ेशन का दबाव अक्सर ज़्यादा होता है। गवर्नेंस ढाँचे में एक एक्सटेंशन रिव्यू फ़ोरम रखिए, ताकि हर गैप पर दर्ज फ़ैसला हो: कॉन्फ़िगर करें, released API से एक्सटेंड करें, या ख़ारिज करें।

US federal: SAP NS2

मैंने US federal प्रोग्राम का नेतृत्व नहीं किया है, इसलिए यह सिर्फ़ सार्वजनिक रिकॉर्ड पर टिप्पणी है। US federal और रक्षा क्लाउड वर्कलोड SAP National Security Services (SAP NS2) के ज़रिए चलते हैं, जो SAP की अलग US सहायक कंपनी है और S/4HANA Cloud Private Edition को सिर्फ़ US के संचालन और कर्मियों के साथ देती है। 2025 में DISA ने इसे S/4HANA Cloud Private Edition और SAP BTP के लिए FedRAMP+ Impact Level 5 पर अस्थायी ऑथराइज़ेशन दिया। अक्टूबर 2025 में SAP US Treasury के FM QSMO marketplace में शामिल हुआ, federal वित्तीय प्रबंधन के लिए। इन प्रोग्रामों के पार्टनर्स के पास मेल खाते ऑथराइज़ेशन और क्लियर्ड स्टाफ़ होना ज़रूरी है, जो शॉर्टलिस्ट को बहुत छोटा कर देता है।

AI और डेटा संप्रभुता

क्लाउड-होस्टेड मॉडल या साझा इन्फ्रास्ट्रक्चर पर निर्भर AI फ़ीचर उन नियमों से टकरा सकते हैं जो नागरिकों के डेटा को देश से बाहर जाने या साझा प्लेटफ़ॉर्म पर प्रोसेस होने से रोकते हैं।

व्यावहारिक रेखा यह है: इम्प्लीमेंटेशन टीम प्रोजेक्ट सामग्री पर जो AI इस्तेमाल करती है (SAP Cloud ALM में रिक्वायरमेंट ड्राफ़्ट, Copilot में मीटिंग सारांश, Confluence में फ़ैसलों के लॉग), वह आमतौर पर ठीक है, बशर्ते उससे होकर नागरिकों का कोई डेटा न जाए। जो AI संप्रभु नागरिक डेटा को रियल टाइम में प्रोसेस करता है, जैसे ऑटोमेटेड केस रूटिंग या टैक्स रिकॉर्ड पर प्रेडिक्टिव एनालिटिक्स, उसे डिप्लॉयमेंट से पहले स्पष्ट डेटा रेज़िडेंसी समीक्षा चाहिए। कुछ फ़ीचर सॉवरेन कॉन्फ़िगरेशन में बिल्कुल उपलब्ध नहीं होते। वेंडर डेमो इस टकराव की ओर इशारा नहीं करेगा। महीनों बाद की लीगल समीक्षा करेगी।

सार्वजनिक क्षेत्र के क्लाउड के लिए कॉन्ट्रैक्ट से पहले की चेकलिस्ट

दस्तख़त से पहले इन सबकी लिखित पुष्टि कीजिए:

1. प्रोडक्शन, नॉन-प्रोडक्शन और डिज़ास्टर रिकवरी के लिए होस्टिंग क्षेत्र
2. सपोर्ट एक्सेस सहित सीमा-पार डेटा रूटिंग पर पाबंदियाँ
3. स्टोर किए गए डेटा (at rest) और ट्रांज़िट में एन्क्रिप्शन, और चाबियाँ किसके पास हैं
4. बैकअप कहाँ रखे जाते हैं और उन पर किस तरह का नियंत्रण है
5. प्रोवाइडर का कौन-सा स्टाफ़ सिस्टम तक पहुँच सकता है, किन देशों से, और एक्सेस कैसे लॉग होता है
6. कौन-से AI फ़ीचर स्कोप में हैं, वे डेटा कहाँ प्रोसेस करते हैं और क्या उन्हें बंद किया जा सकता है
7. कॉन्ट्रैक्ट ख़त्म होने पर डेटा लौटाने और मिटाने की शर्तें

सार्वजनिक क्षेत्र के अनुभव वाले कंसल्टेंट। फ़ंड अकाउंटिंग, ग्रांट, सरकारी प्रोक्योरमेंट और राजस्व संग्रह ख़ास डोमेन हैं। जिन कंसल्टेंट के पास सिर्फ़ व्यावसायिक SAP का अनुभव है, वे ग़लत डिज़ाइन पैटर्न लगाते हैं।

सरकारी अकाउंटिंग जानने वाले फ़ाइनेंस लीड। IPSAS, फ़ंड अकाउंटिंग और बहु-वर्षीय बजट स्टैंडर्ड व्यावसायिक FI नहीं हैं। आपके बिज़नेस प्रतिनिधियों को यह फ़र्क़ पता होना चाहिए। मेरी SAP FICO गाइड उस व्यावसायिक बेसलाइन को कवर करती है जिसे उन्हें अपने हिसाब से ढालना होगा।

पहले दिन से कमरे में अनुपालन और लीगल। डिज़ाइन वर्कशॉप में, अंत में सलाह लेने के लिए नहीं। ब्लूप्रिंट में लिए गए अनुपालन के फ़ैसले go-live के बाद लिए गए फ़ैसलों से सस्ते पड़ते हैं।

नामित डेटा ओनर। नागरिक, वेंडर, वित्तीय और कर्मचारी डेटा के लिए एक-एक व्यक्ति, जिसके पास फ़ैसले का अधिकार हो और डेटा की गुणवत्ता की जवाबदेही।

जो अनुपालन सिस्टम में लागू है, वह ऑडिट में टिकता है। जो नीति में लिखा है और व्यवहार में बायपास होता है, वह नहीं टिकता।

सार्वजनिक क्षेत्र का SAP इम्प्लीमेंटेशन व्यावसायिक SAP से अलग कैसे है?

तीन बातों में: अकाउंटिंग ढाँचा, प्रोक्योरमेंट नियम और डेटा गवर्नेंस।

सार्वजनिक क्षेत्र की अकाउंटिंग राजस्व और ख़र्च को फ़ंड, ग्रांट और बजट वर्षों के हिसाब से ट्रैक करती है, जिसके लिए PSM चाहिए, और राजस्व एजेंसियों के लिए PSCD। सार्वजनिक प्रोक्योरमेंट क़ानूनी ढाँचों पर चलता है जो पारदर्शिता, प्रतिस्पर्धी टेंडरिंग और तयशुदा अप्रूवल चेन अनिवार्य करते हैं। नागरिकों का डेटा, टैक्स रिकॉर्ड और कर्मचारियों की जानकारी पर संप्रभुता की ज़रूरतें लागू होती हैं, जो तय करती हैं कि सिस्टम कहाँ और कैसे होस्ट हो सकता है।

सार्वजनिक क्षेत्र के SAP में सबसे आम अनुपालन विफलताएँ क्या हैं?

ज़्यादातर ऑडिट आपत्तियाँ चार से आती हैं: सेग्रीगेशन ऑफ़ ड्यूटीज़ की कमियाँ, ऑडिट ट्रेल का अभाव, डेटा रेज़िडेंसी का उल्लंघन, और प्रोक्योरमेंट दस्तावेज़ों का सिस्टम के बजाय ईमेल में रहना। हर एक डिज़ाइन की समस्या है जिसे कॉन्फ़िगरेशन और प्रोसेस रोक सकते हैं, और go-live के बाद हर एक को ठीक करना कहीं ज़्यादा महँगा है।

SAP PSM क्या है और कब चाहिए?

SAP Public Sector Management (PSM) सरकारी अकाउंटिंग को कवर करता है, जो स्टैंडर्ड Financial Accounting नहीं करता: फ़ंड अकाउंटिंग, ग्रांट मैनेजमेंट, बजट उपलब्धता नियंत्रण जो अधिकृत बजट से आगे ख़र्च रोकता है, और कैरी-फ़ॉरवर्ड नियमों के साथ बहु-वर्षीय प्रतिबद्धताएँ।

फ़ंड-आधारित बजटिंग, ग्रांट फ़ंडिंग या बहु-वर्षीय पूँजीगत कार्यक्रमों वाली हर एजेंसी को इसकी ज़रूरत है। राजस्व और टैक्स एजेंसियों को नागरिकों की प्राप्य राशि, रिफ़ंड और वसूली के लिए PSCD भी चाहिए। चार्ट ऑफ़ अकाउंट्स, फ़ंड ढाँचा और बजट नियम उन अकाउंटिंग मानकों के हिसाब से डिज़ाइन कीजिए जो आप पर लागू होते हैं।

सार्वजनिक क्षेत्र के SAP क्लाउड डिप्लॉयमेंट में डेटा रेज़िडेंसी कैसे सँभालनी चाहिए?

कॉन्ट्रैक्ट पर दस्तख़त होने से पहले उसकी पुष्टि कीजिए और उसे दर्ज कीजिए। कॉन्ट्रैक्ट में डेटा सेंटर क्षेत्रों के नाम हों, सीमा-पार रूटिंग पर पाबंदी हो, बैकअप शामिल हों और यह तय हो कि प्रोवाइडर का कौन-सा स्टाफ़ सिस्टम तक, कहाँ से पहुँच सकता है।

फिर उसे तकनीकी रूप से परखिए: होस्टिंग क्षेत्र की पुष्टि कीजिए, स्टोरेज और ट्रांज़िट में एन्क्रिप्शन जाँचिए, और एडमिन एक्सेस को सही क्षेत्राधिकार के नामित लोगों तक सीमित कीजिए। go-live के बाद रेज़िडेंसी की समस्या खोजना महँगा और सार्वजनिक होता है।

सार्वजनिक क्षेत्र के लिए RISE with SAP क्या है?

RISE with SAP SAP की सब्सक्रिप्शन पेशकश है, आमतौर पर S/4HANA Cloud Private Edition पर, जिसमें SAP इन्फ्रास्ट्रक्चर और तकनीकी संचालन चलाता है। यह उन एजेंसियों के लिए ठीक बैठता है जहाँ SAP सही ऑथराइज़ेशन के साथ देश के भीतर सत्यापित होस्टिंग दिखा सकता है, और यह छोटी इंटरनल Basis टीम वाली एजेंसियों की मदद करता है।

यह SAP को एप्लिकेशन या प्रोसेस के अनुपालन का ज़िम्मेदार नहीं बनाता। सेग्रीगेशन ऑफ़ ड्यूटीज़, वर्कफ़्लो और टेंडर रिकॉर्ड एजेंसी और उसके पार्टनर के पास ही रहते हैं। US में federal और रक्षा क्लाउड वर्कलोड इसके बजाय SAP NS2 के ज़रिए चलते हैं।

क्या सार्वजनिक क्षेत्र का SAP इम्प्लीमेंटेशन चरणबद्ध होना चाहिए या एक साथ?

ज़्यादातर सार्वजनिक क्षेत्र के संगठनों के लिए चरणबद्ध। बदलाव सँभालने की क्षमता सीमित होती है, अनुपालन की ज़रूरतें अक्सर धीरे-धीरे सामने आती हैं, और पूरे go-live के बाद की अनुपालन विफलता, सीमित पहले चरण में मिली विफलता से ज़्यादा महँगी पड़ती है।

फ़ाइनेंस और प्रोक्योरमेंट आमतौर पर पहले जाते हैं, पेरोल और HR उसके बाद, नागरिकों को दी जाने वाली सेवाएँ उसके भी बाद। पूरा go-live तब चल सकता है जब योजना, डेटा, टीम की क्षमता और अनुपालन दस्तावेज़ीकरण, सब कॉन्फ़िगरेशन से पहले तैयार हों। यह दुर्लभ है।

सार्वजनिक क्षेत्र के SAP में go-live के बाद ऑडिट की तैयारी कैसी दिखती है?

अच्छी तरह लागू किए गए सिस्टम में ऑडिट की तैयारी रिपोर्ट जनरेट करने जैसी बन जाती है। अप्रूवल इतिहास document flow में होता है, टेंडर रिकॉर्ड प्रोक्योरमेंट दस्तावेज़ों में और बजट की खपत PSM में।

यह तभी सच है जब डेटा ठीक से मेंटेन किया गया हो। बायपास हुए वर्कफ़्लो ट्रेल में खाली जगहें छोड़ते हैं, और सिस्टम के बाहर रखे टेंडर रिकॉर्ड सिस्टम से निकाले नहीं जा सकते। ऑडिट की तैयारी उतनी ही प्रोसेस अनुशासन की बात है जितनी कॉन्फ़िगरेशन की।