SAP टेस्ट डेटा मैनेजमेंट: मास्क किया हुआ, प्रोडक्शन-स्तर का डेटा

SAP टेस्ट डेटा मैनेजमेंट वह तरीका है जिससे आप हर टेस्ट सिस्टम को ऐसा डेटा देते हैं जो प्रोडक्शन की तरह व्यवहार करे, पर असली लोगों की जानकारी उजागर न करे। मेरा नियम सीधा है: मास्क किया हुआ डेटा, पर प्रोडक्शन स्तर का, वॉल्यूम में भी और वास्तविकता में भी।

पतला, हाथ से बनाया गया डेटा उन डिफ़ेक्ट को छिपा देता है जो मायने रखते हैं। बिना मास्क का प्रोडक्शन डेटा ग्राहकों, सप्लायर्स और कर्मचारियों के रिकॉर्ड को ऐसे सिस्टम में रख देता है जिनके कंट्रोल प्रोडक्शन से कमज़ोर हैं।

टेस्ट डेटा एक बड़े टेस्टिंग प्लान का एक हिस्सा है। मेरी SAP टेस्टिंग क्या है गाइड टेस्ट के प्रकार, उनके ज़िम्मेदार और SAP Activate में उनकी जगह कवर करती है।

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

टेस्टिंग की जो विफलता मैंने सबसे ज़्यादा देखी है, वह है सिस्टम इंटीग्रेशन टेस्टिंग (SIT) और यूज़र एक्सेप्टेंस टेस्टिंग (UAT) में पर्याप्त टेस्टिंग न होना। कमज़ोर टेस्ट डेटा उन तरीकों में से एक है जिनसे यह चुपचाप होता है। टेस्ट केस चलते हैं, नतीजे हरे दिखते हैं, और जो केस टूटते, उनके पास टूटने के लिए डेटा ही नहीं था।

इसीलिए मैं प्रोडक्शन-स्तर के डेटा पर ज़ोर देता हूँ। इसका मतलब है चार बातें:

1. वॉल्यूम। तालिकाओं का आकार प्रोडक्शन के क़रीब, ताकि रिपोर्ट, जॉब और सर्च वास्तविक पंक्ति संख्या पर चलें।
2. विविधता। वे अजीब रिकॉर्ड जो प्रोडक्शन में असल में होते हैं: ब्लॉक किए गए वेंडर, आंशिक डिलीवरी, क्रेडिट नोट, विदेशी मुद्राएँ, पुराने खुले आइटम।
3. इतिहास। इतने बंद पीरियड कि एजिंग, डेप्रिसिएशन और ईयर-एंड रन का कोई मतलब हो।
4. अखंडता। ऐसे दस्तावेज़ जो कॉपी और मास्किंग के बाद भी मॉड्यूल के पार सही जुड़े रहें।

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

लगभग ख़ाली डेटाबेस पर कंकरेंसी टेस्ट बहुत कम साबित करता है। मेरी SAP परफ़ॉर्मेंस टेस्टिंग गाइड बताती है कि ये टेस्ट कैसे सेट करें।

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

EU का General Data Protection Regulation (GDPR) वह संदर्भ है जिससे ज़्यादातर संगठन काम करते हैं, और कई राष्ट्रीय क़ानून इसी तरह की राह पर चलते हैं। GDPR का Recital 26 एक ऐसा अंतर करता है जो हर SAP टीम को पता होना चाहिए।

1. Pseudonymised डेटा भी व्यक्तिगत डेटा है। अगर अतिरिक्त जानकारी, जैसे कोई मैपिंग तालिका, से डेटा को वापस किसी व्यक्ति से जोड़ा जा सकता है, तो रेगुलेशन लागू रहता है।
2. Anonymous डेटा इसके दायरे से बाहर है। जो डेटा अब किसी की पहचान नहीं कर सकता, वह कवर नहीं होता।

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

पाँच आम रास्ते हैं। ज़्यादातर प्रोग्राम एक से ज़्यादा इस्तेमाल करते हैं, क्योंकि हर टेस्ट चरण को कुछ अलग चाहिए।

तालिका उन बिंदुओं पर इनकी तुलना करती है जो तय करते हैं कि कौन सा ठीक बैठेगा।

तरीका	आपको क्या मिलता है	वॉल्यूम	प्राइवेसी कैसे संभलती है	सबसे उपयुक्त
फ़ुल सिस्टम कॉपी	प्रोडक्शन की हूबहू कॉपी, हर क्लाइंट और तालिका	पूरा	मास्किंग कॉपी के बाद, यूज़र्स को एक्सेस मिलने से पहले चलनी चाहिए	परफ़ॉर्मेंस टेस्ट, मॉक कन्वर्ज़न, कटओवर रिहर्सल
क्लाइंट कॉपी	एक क्लाइंट, एक सिस्टम के भीतर या सिस्टम के बीच कॉपी; कॉपी प्रोफ़ाइल तय करती है कि मास्टर और ट्रांज़ैक्शन डेटा भी आएगा या नहीं	पूरा या केवल कस्टमाइज़िंग	एप्लिकेशन डेटा कॉपी होने पर सिस्टम कॉपी जैसा ही	नए टेस्ट या ट्रेनिंग क्लाइंट, किसी क्लाइंट को ज्ञात स्थिति में रीसेट करना
SAP Test Data Migration Server (TDMS)	समय या संगठनात्मक इकाई के हिसाब से चुनी गई छोटी कॉपी, स्क्रैम्बलिंग के साथ	कम	टूल के भीतर स्क्रैम्बलिंग के नियम	मौजूदा SAP Business Suite लैंडस्केप जिनके पास इसका लाइसेंस पहले से है
पार्टनर के सेलेक्टिव कॉपी टूल	चुने गए बिज़नेस ऑब्जेक्ट या हिस्से, माँग पर कॉपी, रास्ते में मास्क	कम, लक्षित	टूल के भीतर मास्किंग के नियम, कॉपी के दौरान लागू	नियमित रिफ़्रेश, रिग्रेशन डेटा, डिफ़ेक्ट दोहराना
बनाया गया या माइग्रेट किया गया डेटा	स्क्रिप्ट, माइग्रेशन लोड या मैनुअल एंट्री से बना डेटा	जितना आप बनाएँ	शुरू से बनाया गया हो तो कोई असली व्यक्तिगत डेटा नहीं	शुरुआती यूनिट टेस्ट, go-live से पहले ग्रीनफ़ील्ड प्रोजेक्ट

फ़ुल सिस्टम और क्लाइंट कॉपी

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

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

SAP Test Data Migration Server

SAP Test Data Migration Server (TDMS) प्रोडक्शन डेटा से छोटे नॉन-प्रोडक्शन सिस्टम बनाता है, संवेदनशील फ़ील्ड की स्क्रैम्बलिंग के साथ। यह SAP Business Suite पर विकसित हुआ, और SAP Help Portal पर मौजूदा दस्तावेज़ रिलीज़ 4.0 SP14 के लिए हैं।

मुझे मौजूदा S/4HANA रिलीज़ पर TDMS की कवरेज या किसी नामित उत्तराधिकारी के बारे में SAP का कोई आधिकारिक बयान नहीं मिला। अगर आप इस पर निर्भर रहने की योजना बना रहे हैं, तो SAP से लिखित में पूछिए कि क्या यह आपकी लक्ष्य रिलीज़ और आपके डिप्लॉयमेंट मॉडल को सपोर्ट करता है, RISE with SAP समेत।

SAP Landscape Transformation और शेल कॉपी

SAP Landscape Transformation एनालिसिस और ट्रांसफ़ॉर्मेशन टूल का एक सेट है जिसे SAP सेलेक्टिव डेटा ट्रांज़िशन में इस्तेमाल करता है। SAP Learning शेल कन्वर्ज़न को प्रोडक्शन सिस्टम की ऐसी कॉपी बताता है जो मास्टर और ट्रांज़ैक्शन डेटा के बिना बनाई जाती है, फिर S/4HANA में कन्वर्ट की जाती है।

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

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

1. EPI-USE Labs Data Sync Manager। SAP ABAP लैंडस्केप में डेटा कॉपी और मास्क करने का एक सूट, जिसमें lean क्लाइंट, ऑब्जेक्ट-स्तर की कॉपी और पहले से तय नियमों से मास्किंग शामिल है। EPI-USE Labs कहता है कि Data Sync Manager SAP S/4HANA और S/4HANA Cloud के साथ इंटीग्रेशन के लिए प्रमाणित है और RISE with SAP के साथ काम करता है।
2. SNP Kyano Test Data Organizer। पूरे सिस्टम के बजाय वह डेटा निकालता है जो किसी टेस्ट को चाहिए, और प्रोविज़न करते समय संवेदनशील डेटा मास्क करता है। SNP Test Data Organizer को RISE with SAP Private Cloud Edition के साथ संगत बताता है।
3. Qlik Gold Client। चुने हुए ट्रांज़ैक्शनल डेटा को प्रोडक्शन से नॉन-प्रोडक्शन लक्ष्यों तक कॉपी और सिंक्रोनाइज़ करता है, मौजूदा सिस्टम के लिए स्टैटिक मास्किंग और रास्ते के डेटा के लिए डायनैमिक मास्किंग के साथ।
4. Natuvion DCS Protect। व्यक्तिगत डेटा ढूँढता है और टेस्ट, क्वालिटी, डेवलपमेंट और ट्रेनिंग सिस्टम में anonymisation या pseudonymisation लागू करता है। Natuvion इसे टेस्ट माइग्रेशन और चालू संचालन के लिए पेश करता है, और उस पेज पर S/4HANA का ज़िक्र नहीं करता, इसलिए कवरेज सीधे पुष्टि कीजिए।

ख़रीदने से पहले हर वेंडर से अपने ही सिस्टम पर इनके जवाब माँगिए:

1. यह आज कौन सी S/4HANA रिलीज़ और डिप्लॉयमेंट मॉडल सपोर्ट करता है?
2. क्या यह डेटा के प्रोडक्शन से निकलने से पहले मास्क करता है, या लक्ष्य में पहुँचने के बाद?
3. क्या मास्किंग जुड़े हुए सिस्टम में एक जैसी रहती है, ताकि S/4HANA में मास्क किया गया ग्राहक आपके CRM या डेटा वेयरहाउस में उसी ग्राहक से मेल खाए?
4. प्रोडक्शन वॉल्यूम पर एक कंपनी कोड के रिफ़्रेश में कितना समय लगता है?
5. जब आप कस्टम तालिकाएँ या फ़ील्ड जोड़ते हैं, तो मास्किंग के नियम कौन मेंटेन करता है?

हर टेस्ट चरण को डेटा अलग वजह से चाहिए। S/4HANA प्रोग्राम में टेस्ट डेटा की योजना बनाते समय मैं यहीं से शुरू करता हूँ।

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

UAT पर अतिरिक्त ध्यान चाहिए। यूज़र एक्सेप्टेंस टेस्टिंग की ज़िम्मेदारी बिज़नेस की होनी चाहिए, और मेरी राय में इसे कम से कम 6 से 8 सप्ताह चाहिए।

यूज़र्स को ऐसा डेटा दीजिए जिसे वे पहचानें: उनके अपने ग्राहक, मटीरियल और प्राइस लिस्ट, भले ही मास्क किए गए नामों के साथ। मेरी SAP यूज़र एक्सेप्टेंस टेस्टिंग गाइड बताती है कि इसे कैसे चलाएँ।

मॉक कन्वर्ज़न भी इसी तर्क पर चलते हैं। ब्राउनफ़ील्ड कन्वर्ज़न में मैं तीन मॉक कन्वर्ज़न प्लान करता हूँ, और हर एक को प्रोडक्शन की हाल की कॉपी पर चलना चाहिए।

मेरे अनुभव में डेटा माइग्रेशन प्रोग्राम का 30 से 40 प्रतिशत प्रयास है, इसलिए उन रन के लिए डेटा एक्सेस की योजना माइग्रेशन टीम के साथ बनाइए। SAP डेटा माइग्रेशन क्यों विफल होता है पर मेरा लेख बताता है कि मॉक लोड आपस में कैसे जुड़ते हैं।

दो लैंडस्केप, दो रिफ़्रेश प्लान

प्रोग्राम के दौरान मैं दो अलग लैंडस्केप चलाता हूँ: एक प्रोजेक्ट के लिए और एक बिज़नेस ऐज़ यूज़ुअल (BAU) के लिए। तब लाइव सपोर्ट के बदलाव और प्रोजेक्ट के बदलाव अलग-अलग टेस्ट होते हैं।

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

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

टेस्टिंग में प्रोग्राम का लगभग 35 प्रतिशत प्रयास लगता है। टेस्ट डेटा की योजना उसी प्रयास के भीतर बनाइए, SIT से पहले वाले हफ़्ते में नहीं।

मैं यह क्रम अपनाऊँगा:

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

फिर इसे एक गेट बनाइए। हर साइकिल की स्ट्रैटेजी, एंट्री क्राइटेरिया और एग्ज़िट क्राइटेरिया मेरी S/4HANA टेस्टिंग स्ट्रैटेजी गाइड में हैं, और टेस्ट डेटा की तैयारी हर राउंड के एंट्री क्राइटेरिया में होनी चाहिए।

ठोस अगला कदम: हर उस नॉन-प्रोडक्शन सिस्टम की सूची बनाइए जिसमें आज प्रोडक्शन डेटा की कॉपी है, और जाँचिए कि उनमें से किन्हें मास्क किया गया था।

अगर आप किसी S/4HANA प्रोग्राम के टेस्ट डेटा तरीके या टेस्टिंग प्लान पर स्वतंत्र राय चाहते हैं, तो आप यहाँ मुझसे संपर्क कर सकते हैं।

SAP टेस्ट डेटा मैनेजमेंट क्या है?

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

क्या मैं SAP टेस्टिंग के लिए प्रोडक्शन डेटा इस्तेमाल कर सकता हूँ?

केवल मास्क करने के बाद, और तब भी एक्सेस कंट्रोल के साथ। GDPR के तहत pseudonymised डेटा भी व्यक्तिगत डेटा है, इसलिए मास्क की गई कॉपी को भी एक उद्देश्य, एक्सेस के नियम और रिटेंशन का नियम चाहिए। पहली कॉपी से पहले अपने डेटा प्रोटेक्शन ऑफ़िसर के साथ मास्किंग के नियम तय कीजिए।

क्या SAP TDMS अब भी S/4HANA के लिए उपलब्ध है?

SAP Help Portal पर TDMS के मौजूदा दस्तावेज़ रिलीज़ 4.0 SP14 के लिए हैं, और TDMS SAP Business Suite पर विकसित हुआ था। मुझे मौजूदा S/4HANA रिलीज़ पर इसकी कवरेज के बारे में SAP का कोई आधिकारिक बयान नहीं मिला। इसके इर्द-गिर्द योजना बनाने से पहले SAP से लिखित में पूछिए।

सेलेक्टिव SAP टेस्ट डेटा कौन से टूल बनाते हैं?

SAP Test Data Migration Server, साथ में EPI-USE Labs Data Sync Manager, SNP Kyano Test Data Organizer और Qlik Gold Client जैसे पार्टनर प्रोडक्ट। Natuvion DCS Protect टेस्ट सिस्टम में डेटा को anonymise और pseudonymise करने पर केंद्रित है। हर एक को अपनी S/4HANA रिलीज़ और डिप्लॉयमेंट मॉडल के सामने जाँचिए।

SAP परफ़ॉर्मेंस टेस्टिंग के लिए मुझे कितना टेस्ट डेटा चाहिए?

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