
विषय-सूची
- दोनों में क्या-क्या शामिल होता है
- कब कौन सा तरीका सही है
- रोलआउट कहाँ गड़बड़ाते हैं
- लोकल टीमों पर थोपा गया टेम्पलेट
- टेस्टिंग में सामने आती लोकलाइज़ेशन की ज़रूरतें
- मास्टर डेटा जो मेल नहीं खाता
- ऐसी ट्रेनिंग जो ग्लोबल सिस्टम समझाती है, लोकल नहीं
- टेम्पलेट RISE या GROW पर चले तो क्या बदलता है
- रोलआउट रेडीनेस चेकलिस्ट
- दो उदाहरण
- अक्सर पूछे जाने वाले सवाल
SAP इम्प्लीमेंटेशन वहाँ सिस्टम खड़ा करता है जहाँ पहले कुछ नहीं था। रोलआउट में ग्रुप में कहीं पहले से चल रहे SAP सिस्टम को किसी नए देश, एंटिटी या बिज़नेस यूनिट तक बढ़ाया जाता है। ज़्यादातर लोग मान लेते हैं कि रोलआउट बस एक छोटा इम्प्लीमेंटेशन है। इन प्रोग्राम में किसी भी तकनीकी फ़ैसले से ज़्यादा दोबारा काम इसी धारणा की वजह से होता है।
एक बार मैंने एक CFO को यह मानने दिया कि क्षेत्रीय SAP रोलआउट प्लग-एंड-प्ले होगा। मैंने जोखिम समझाए थे, पर अड़ा नहीं। हम ग्लोबल टेम्पलेट इस्तेमाल कर रहे थे, और उन्होंने मान लिया कि हर लोकेशन बिना ज़्यादा मेहनत के उसमें बैठ जाएगी। ऐसा नहीं हुआ। एक क्षेत्र को अतिरिक्त टैक्स हैंडलिंग चाहिए थी। दूसरे में स्थानीय क़ानूनों की वजह से कर्मचारी डेटा के कुछ फ़ील्ड अनिवार्य थे। जो कॉपी-पेस्ट का काम लग रहा था, उसमें असली कस्टमाइज़ेशन करना पड़ा।
इसलिए यह चुनाव तय करता है कि आप संसाधन कैसे लगाते हैं, बजट कैसे बनाते हैं और काम कैसे चलाते हैं। इसे गलत चुना तो सिस्टम फिर भी go-live कर सकता है, बस उस तरह नहीं जैसा आपने योजना बनाई थी।
इम्प्लीमेंटेशन शून्य से शुरू होता है। आप स्कोप तय करते हैं, प्रोसेस मैप करते हैं, कॉन्फ़िगर करते हैं, डेटा माइग्रेट करते हैं और इंटीग्रेशन बनाते हैं। यह तब लागू होता है जब संगठन में SAP है ही नहीं, या किसी पुराने सिस्टम को पूरी तरह बदलना है।
रोलआउट उस डिज़ाइन को दोबारा इस्तेमाल करता है जो पहले से काम कर रहा है: प्रोसेस, कॉन्फ़िगरेशन, मास्टर डेटा के मानक। काम उस फ़ासले का है जो टेम्पलेट और नई लोकेशन की ज़रूरत के बीच है। टैक्स, वैधानिक रिपोर्टिंग, करेंसी, भाषाएँ, स्थानीय इंटीग्रेशन और वे लोग जो इसे इस्तेमाल करेंगे।
- लोकल यूज़रस्थानीय प्रोसेस के हिसाब से, स्थानीय भाषा में ट्रेनिंग
- लोकल इंटीग्रेशननए देश के बैंक, टैक्स फ़ाइलिंग और लॉजिस्टिक्स सिस्टम
- लोकल डेटाग्राहक, वेंडर और मटीरियल डेटा, ग्लोबल मानकों से मैप किया हुआ
- लोकल ज़रूरतेंटैक्स, वैधानिक रिपोर्टिंग और अनिवार्य फ़ील्ड। सिर्फ़ ज़रूरतें, पसंद नहीं
- ग्लोबल टेम्पलेटप्रोसेस, कॉन्फ़िगरेशन और मास्टर डेटा के मानक जो पहले से काम करते हैं
व्यवहार में दोनों की तुलना ऐसे दिखती है:
| क्षेत्र | SAP इम्प्लीमेंटेशन | SAP रोलआउट |
|---|---|---|
| शुरुआती स्थिति | SAP नहीं है, या कोई पुराना सिस्टम बदला जा रहा है | SAP मुख्यालय या किसी दूसरी एंटिटी में पहले से चल रहा है |
| डिज़ाइन | नया डिज़ाइन, fit-to-standard | ग्लोबल टेम्पलेट, नियंत्रित स्थानीय बदलावों के साथ |
| आम अवधि | 12 से 24 महीने, बड़े ग्रुप में ज़्यादा | हर लोकेशन पर 6 से 12 महीने |
| मुख्य जोखिम | हर वर्कस्ट्रीम में अनजानी बातें | लोकलाइज़ेशन और स्थानीय तैयारी |
| डेटा | पुराने सिस्टम से पूरा लोड | स्थानीय डेटा, ग्लोबल मास्टर डेटा मानकों से मैप किया हुआ |
| टेस्टिंग | पूरा चक्र: यूनिट, इंटीग्रेशन, UAT, परफ़ॉर्मेंस | लोकलाइज़ेशन, लोकल इंटरफ़ेस, UAT |
| चेंज मैनेजमेंट | शून्य से पूरा प्रोग्राम | मौजूदा सामग्री को लोकल टीमों के हिसाब से ढालना |
इम्प्लीमेंटेशन तब सही बैठता है जब:
- संगठन ने पहले कभी SAP इस्तेमाल नहीं किया।
- मौजूदा सिस्टम फेल हो रहा है और उसे पूरा बदलना है।
- मर्जर, अधिग्रहण या नया ऑपरेटिंग मॉडल आने से पुराना डिज़ाइन अब फ़िट नहीं बैठता।
- कोई इंडस्ट्री सॉल्यूशन पहली बार आ रहा है, जैसे SAP for Utilities या SAP for Public Sector।
- आपके स्कोप को कवर करने वाला कोई मौजूदा टेम्पलेट नहीं है।
इम्प्लीमेंटेशन में समय ज़्यादा लगता है और शुरुआती खर्च भी। बदले में आपको ऐसा डिज़ाइन मिलता है जो आपके बिज़नेस से मेल खाता है, और ऐसी टीम जो हर फ़ैसले के पीछे की वजह समझती है। जो कंपनियाँ requirements में जल्दबाज़ी करती हैं, वे बाद में गलतियाँ ठीक करने पर 30 से 50 प्रतिशत ज़्यादा खर्च करती हैं। मैंने यह बार-बार होते देखा है।
रोलआउट तब सही बैठता है जब SAP ग्रुप में कहीं पहले से अच्छी तरह चल रहा हो, कोर प्रोसेस स्थिर हों, और टेम्पलेट इतना लचीला हो कि स्थानीय ज़रूरतें बिना टूटे समा जाएँ। इन तीनों में से कोई भी डगमगा रहा हो, तो टेम्पलेट को कहीं भी रोलआउट करने से पहले ठीक करें।
तकनीकी हिस्सा आम तौर पर समय पर पूरा हो जाता है। देरी लोगों से आती है, और उन मान्यताओं से जो नए देश में लागू नहीं होतीं।
लोकल टीमों पर थोपा गया टेम्पलेट
जो उत्तरी अमेरिका में अच्छा चला, वह एशिया या मध्य पूर्व में कमज़ोर पड़ सकता है। टैक्स ढाँचे, अप्रूवल वर्कफ़्लो और डेटा एंट्री के नियम अलग होते हैं। मैंने एक ऐसी कंपनी के साथ काम किया जिसने मान लिया था कि उसका यूरोपीय टेम्पलेट मध्य पूर्व में भी चलेगा। नतीजा देरी, दोबारा लिखाई और काफ़ी तनाव रहा। बिज़नेस प्रोसेस बस बहुत अलग थे।
इसका हल यह है कि नई लोकेशन को ऐसा बिज़नेस ओनर दें जिसके पास फ़ैसले लेने का अधिकार हो। जब मुख्यालय की टीमें उन जगहों के प्रोसेस तय करती हैं जिन्हें वे समझती नहीं, तो ऐसे डिज़ाइन बनते हैं जो स्थानीय यूज़र से टकराते ही बिखर जाते हैं।
टेस्टिंग में सामने आती लोकलाइज़ेशन की ज़रूरतें
टैक्स हैंडलिंग, वैधानिक रिपोर्टें और अनिवार्य डेटा फ़ील्ड डिज़ाइन शुरू होने से पहले पक्के हो जाने चाहिए। मैंने एक क्लाइंट का साथ दिया था जहाँ टैक्स कॉन्फ़िगरेशन के एक मामूली फ़र्क़ ने उनका go-live एक महीने से ज़्यादा टाल दिया। मामला तकनीक का नहीं था। स्थानीय ज़रूरतों को किसी ने समय रहते जाँचा ही नहीं था।
मास्टर डेटा जो मेल नहीं खाता
प्रोडक्ट कोड, ग्राहक नंबर और वेंडर वर्गीकरण ग्लोबल मानकों से मेल खाने चाहिए। go-live के बाद मिली गड़बड़ियाँ ठीक करना महँगा पड़ता है और कंसोलिडेटेड रिपोर्टिंग तोड़ देता है। स्थानीय डेटा को ग्लोबल मॉडल से डिज़ाइन के दौरान मैप करें, UAT में नहीं।
ऐसी ट्रेनिंग जो ग्लोबल सिस्टम समझाती है, लोकल नहीं
रोलआउट में अक्सर मूल इम्प्लीमेंटेशन की ट्रेनिंग ही दोबारा इस्तेमाल हो जाती है। वह सामग्री बताती है कि मुख्यालय में सिस्टम कैसे काम करता है। स्थानीय बदलावों के बारे में वह कुछ नहीं बताती। जिन यूज़र्स को समझ नहीं आता कि उनका वर्शन अलग क्यों है, वे वर्कअराउंड बना लेते हैं।
ऊपर का ढाँचा अब भी लागू है। टेम्पलेट का डिप्लॉयमेंट मॉडल बदलने से लागत का गणित और एक्सटेंशन के नियम कुछ बदलते हैं।
RISE with SAP (Private Edition) पर हर नया देश एक सब्सक्रिप्शन में यूज़र जोड़ता है, जिसकी कीमत फ़ुल यूज़र इक्विवेलेंट (FUE) पर तय होती है। लागत का अनुमान लगाना आसान रहता है और इंफ़्रास्ट्रक्चर का काम कम होता है। लागत go-live के बाद भी चलती रहती है, इसलिए विकल्पों की तुलना कई सालों में करें, सिर्फ़ पहले साल में नहीं।
GROW with SAP (Public Edition) पर सबसे पहले जाँचें कि SAP उस देश के लिए लोकल वर्शन देता है या नहीं। फ़रवरी 2024 तक SAP ने 59 देशों और क्षेत्रों के लिए लोकल वर्शन सूचीबद्ध किए थे। दूसरे देशों के लिए SAP का localisation as a self-service प्रोग्राम पार्टनर्स को Configuration Localization Tool से कस्टमर लोकल वर्शन बनाने देता है, जो फ़िलहाल अर्ली एडॉप्टर रूट से उपलब्ध है (SAP Learning)। अगर इनमें से कुछ भी लागू नहीं होता, तो आपके सामने स्कोपिंग की समस्या है, रोलआउट की नहीं।
Clean core हर स्थानीय बदलाव पर लागू होता है। Public Edition एक्सटेंशन सिर्फ़ released इंटरफ़ेस से स्वीकार करता है। Private Edition पर यह गवर्नेंस का चुनाव है, लेकिन हर स्थानीय बदलाव जिसे आप इजाज़त देते हैं, हर अपग्रेड पर दोबारा टेस्ट करने के लिए एक और ऑब्जेक्ट है, और वह हर देश के साथ गुणा होता है। मैं जो अनुशासन लागू करवाता हूँ वह सीधा है: टैक्स क़ानून, वैधानिक रिपोर्टिंग और नियामक आदेश टेम्पलेट से हटने को जायज़ ठहराते हैं। स्थानीय पसंद नहीं।
तकनीकी हिस्सा आम तौर पर समय पर पूरा हो जाता है। देरी तब होती है जब लोकल टीमें तैयार नहीं होतीं या मूल इम्प्लीमेंटेशन की मान्यताएँ नए देश में लागू नहीं होतीं।
अगले देश की तारीख पक्की करने से पहले इन सबमें हाँ लें। हर बिंदु का एक ओनर है।
- लोकल बिज़नेस ओनर (नया देश): नामित, और स्थानीय डिज़ाइन को साइन-ऑफ़ करने का अधिकार रखने वाला।
- टैक्स और लीगल सलाहकार: डिज़ाइन शुरू होने से पहले टैक्स, वैधानिक रिपोर्टिंग और अनिवार्य डेटा फ़ील्ड दस्तावेज़ में दर्ज।
- टेम्पलेट ओनर (मुख्यालय): प्रस्तावित बदलावों की सूची, हर एक पर निशान कि वह ज़रूरत है या पसंद।
- डेटा लीड: स्थानीय ग्राहक, वेंडर और मटीरियल डेटा ग्लोबल मानकों से मैप किया हुआ।
- इंटीग्रेशन लीड: जिन स्थानीय सिस्टम को जुड़ना है, जैसे बैंक, टैक्स फ़ाइलिंग या लॉजिस्टिक्स, उनकी पहचान और स्कोपिंग।
- चेंज लीड: स्थानीय प्रोसेस के हिसाब से, स्थानीय भाषा में और स्थानीय उदाहरणों के साथ ढाली गई ट्रेनिंग।
- प्रोग्राम डायरेक्टर: एक बार में एक लोकेशन, पिछले go-live की सीख अगले में शामिल।
मेरी स्कोप टेम्पलेट गाइड बिंदु 3 में मदद करती है, और प्रोजेक्ट चार्टर गाइड बताती है कि फ़ैसले के अधिकार लिखित में कैसे दर्ज करें।
मिस्र में ग्रीनफ़ील्ड इम्प्लीमेंटेशन। मिस्र की एक क्षेत्रीय मैन्युफ़ैक्चरिंग कंपनी पुराने, आपस में कटे सिस्टम और बहुत सारे मैन्युअल काम में उलझी थी। सप्लाई चेन, प्रोडक्शन ट्रैकिंग और फ़ाइनेंशियल रिपोर्टिंग एक-दूसरे से बात नहीं करते थे। उन्होंने SAP S/4HANA शून्य से लागू किया और फ़ाइनेंस, प्रोक्योरमेंट और प्रोडक्शन को एक ही सिस्टम में जोड़ दिया। उन्होंने ऑटोमेटेड सप्लाई चेन प्लानिंग शुरू की और go-live से पहले चार देशों में 5,000 से ज़्यादा कर्मचारियों को ट्रेनिंग दी। उन्होंने जल्दबाज़ी नहीं की। ऑपरेशनल लागत 25 प्रतिशत और फ़ोरकास्टिंग की गलतियाँ 35 प्रतिशत घटीं।
15 बाज़ारों में रोलआउट। एक रिटेल कंपनी के मुख्यालय में SAP S/4HANA पहले से चल रहा था और उसे 15 नए बाज़ारों में चाहिए था। हर बाज़ार के टैक्स नियम, करेंसी और कारोबारी तौर-तरीक़े अलग थे। उन्होंने ग्लोबल टेम्पलेट से शुरुआत की, हर लोकेशन के लिए उसे ढाला, सब कुछ एक साथ करने के बजाय दो साल में चरणबद्ध रोलआउट किया और हर क्षेत्र के लिए ट्रेनिंग बनाई। नतीजा: फ़ाइनेंशियल कंसोलिडेशन तेज़ हुआ, स्टोरों में रियल-टाइम इन्वेंट्री ट्रैकिंग मिली और ग्रुप स्तर की रिपोर्टिंग 20 प्रतिशत ज़्यादा सटीक हुई।
एक में कुछ ऐसा बन रहा था जो पहले था ही नहीं। दूसरे में कुछ ऐसा बढ़ाया जा रहा था जो काम कर रहा था। दोनों में से कोई प्लग-एंड-प्ले नहीं था। अगर आप पहली तरह के काम की शुरुआत पर हैं, तो SAP इम्प्लीमेंटेशन को सही तरह कैसे शुरू करें पर मेरी गाइड से शुरू करें।
SAP इम्प्लीमेंटेशन और SAP रोलआउट में क्या अंतर है?
इम्प्लीमेंटेशन SAP को शून्य से बनाता है: requirements, प्रोसेस डिज़ाइन, कॉन्फ़िगरेशन, डेटा माइग्रेशन, इंटीग्रेशन, टेस्टिंग और go-live। रोलआउट मौजूदा SAP सिस्टम और उसके ग्लोबल टेम्पलेट को किसी नए देश, एंटिटी या बिज़नेस यूनिट तक बढ़ाता है। रोलआउट का काम टेम्पलेट और स्थानीय ज़रूरतों के बीच के फ़ासले का है: टैक्स, वैधानिक रिपोर्टिंग, भाषा, लोकल इंटीग्रेशन और ट्रेनिंग।
कंपनी को रोलआउट के बजाय इम्प्लीमेंटेशन कब चुनना चाहिए?
इम्प्लीमेंटेशन तब चुनें जब बढ़ाने के लिए कोई SAP है ही नहीं, या किसी पुराने सिस्टम को पूरा बदला जा रहा है। यह तब भी बेहतर रास्ता है जब बिज़नेस मॉडल इतना बदल चुका हो कि मौजूदा डिज़ाइन फ़िट न बैठे, या जब कोई टेम्पलेट ज़रूरी स्कोप को कवर न करता हो। गलत टेम्पलेट का रोलआउट ज़बरदस्ती करने से साफ़ नए डिज़ाइन के मुक़ाबले ज़्यादा दोबारा काम बनता है।
इम्प्लीमेंटेशन के मुक़ाबले SAP रोलआउट में कितना समय लगता है?
इम्प्लीमेंटेशन में आम तौर पर 12 से 24 महीने लगते हैं, बड़े ग्रुप में ज़्यादा। रोलआउट में आम तौर पर हर लोकेशन पर 6 से 12 महीने लगते हैं, जो लोकलाइज़ेशन, इंटीग्रेशन और डेटा पर निर्भर करता है। सबसे बड़ा फ़र्क़ इस बात से पड़ता है कि डिज़ाइन शुरू होने से पहले स्थानीय ज़रूरतें कितनी अच्छी तरह जाँची गई थीं।
कई देशों में SAP रोलआउट की सबसे बड़ी चुनौतियाँ क्या हैं?
चार चुनौतियाँ बार-बार सामने आती हैं। टेम्पलेट जो लोकल टीमों पर उनकी राय के बिना थोप दिए जाते हैं। लोकलाइज़ेशन की ज़रूरतें जो टेस्टिंग के दौरान मिलती हैं। मास्टर डेटा जो ग्लोबल मानकों से मेल नहीं खाता। और ऐसी ट्रेनिंग जो लोकल सिस्टम के बजाय ग्लोबल सिस्टम समझाती है। इनमें से ज़्यादातर तकनीकी नहीं, लोगों और प्लानिंग की समस्याएँ हैं।
क्या SAP रोलआउट हमेशा पूरे इम्प्लीमेंटेशन से सस्ता होता है?
आम तौर पर हाँ, क्योंकि डिज़ाइन पहले से मौजूद और परखा हुआ है। जब किसी देश के टैक्स या पेरोल नियम जटिल हों, कई लोकल इंटीग्रेशन चाहिए हों, या डेटा खराब हो, तो यह बचत घट जाती है। RISE with SAP में हर नए देश का सब्सक्रिप्शन go-live के बाद भी चलता रहता है, इसलिए लागत की तुलना कई सालों में करें।
SAP रोलआउट में ग्लोबल टेम्पलेट कैसे काम करता है?
ग्लोबल टेम्पलेट ग्रुप के मानक प्रोसेस का दस्तावेज़ी और कॉन्फ़िगर किया हुआ SAP डिज़ाइन है। हर रोलआउट उसी से शुरू होता है और उसमें सिर्फ़ वही स्थानीय बदलाव जोड़ता है जो सच में ज़रूरी हैं। हर बदलाव हर अपग्रेड पर मेंटेनेंस की ज़िम्मेदारी बन जाता है, इसलिए इन्हें गवर्न करें: टैक्स क़ानून जैसी ज़रूरतें बदलाव को जायज़ ठहराती हैं, पसंद नहीं।
अगला कदम
क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?
अगर यह लेख किसी ऐसे प्रोग्राम से जुड़ा है जिसमें आप अभी काम कर रहे हैं, तो 30 मिनट की बातचीत अक्सर एक और हफ़्ते के अंदरूनी विश्लेषण से ज़्यादा आगे ले जाती है।




