इस लेख में
छठे भाग में हमने खोला कि ERP परियोजनाएँ क्यों विफल होती हैं: अपरिभाषित प्रक्रिया, अनुपस्थित स्वामी, गंदा डेटा, जल्दबाज़ी में लॉन्च और परिवर्तन के लिए तैयार न की गई टीम। अब हम उन सबकों को एक कार्य योजना में बदलते हैं। सिस्टम चुनना एक दिन का निर्णय है; उसे लागू करना महीनों की परियोजना है, और परिणाम वास्तव में वहीं तय होता है। इस सातवें भाग में हम कार्यान्वयन के चरणों को क्रम से देखते हैं: खोज और प्रक्रिया ब्लूप्रिंट से, डेटा माइग्रेशन तक, फिर परीक्षण तक, फिर गो-लाइव और हाइपरकेयर तक, और फिर उस मानवीय पक्ष तक जहाँ अधिकांश परियोजनाएँ अटक जाती हैं।
खोज और प्रक्रिया ब्लूप्रिंट: बनाने से पहले नक्शा बनाएँ
सफल कार्यान्वयन इंस्टॉलेशन से नहीं, बल्कि खोज चरण से शुरू होता है। आप हर विभाग के साथ बैठते हैं और यह दर्ज करते हैं कि वह आज वास्तव में कैसे काम करता है — न कि काग़ज़ पर उसे कैसे काम करना चाहिए — और फिर उस एक तरीके पर सहमति बनाते हैं जिससे सिस्टम हर प्रक्रिया चलाएगा। इस चरण का परिणाम एक दस्तावेज़ होता है: प्रक्रिया ब्लूप्रिंट, जो हर प्रक्रिया को परिभाषित करता है, उसका स्वामी कौन है, और वह कहाँ शुरू होती है और कहाँ ख़त्म होती है।
यह ब्लूप्रिंट परियोजना का संविधान है। हर विवाद इसकी ओर लौटकर सुलझाया जाता है, और हर अनुकूलन को इसके सामने तौला जाता है। जो परियोजनाएँ खोज को छोड़कर सीधे स्क्रीन पर कूद जाती हैं, वे कमियों को गो-लाइव के बाद खोजती हैं, जब उन्हें ठीक करने की लागत कई गुना होती है।
डेटा माइग्रेशन: ले जाने से पहले साफ़ करें
आपका पुराना डेटा वर्षों में जमा हुई बिखरी स्प्रेडशीट और सिस्टमों में रहता है, और नए सिस्टम में ले जाई जाने वाली सबसे ख़तरनाक चीज़ वही है। सफल माइग्रेशन अपने आप में एक चरण है, कॉपी-पेस्ट नहीं:
- ले जाने से पहले साफ़ करें: दोहराए गए नाम, मेल न खाने वाले बैलेंस, बिना श्रेणी वाली मदें। सिस्टम में आने से पहले इन्हें स्रोत पर ही साफ़ करें, क्योंकि साफ़ सिस्टम में आने वाला गंदा डेटा गंदा ही रहता है और पहले दिन से ही आँकड़ों पर भरोसा हिला देता है।
- मैप करें और सत्यापित करें: अपने पुराने सिस्टम के फ़ील्ड को नए सिस्टम के फ़ील्ड से मिलाएँ, पहले एक परीक्षण बैच माइग्रेट करें, फिर उस पर भरोसा करने से पहले जाँचें कि बैलेंस और कुल योग स्रोत से मेल खाते हैं।
- आप जो इतिहास साथ ले जाते हैं: तय करें कि क्या माइग्रेट करना है और क्या संग्रहित करना है। हर पुराना रिकॉर्ड नए सिस्टम पर बोझ बनने लायक नहीं होता।
नियम: पहले साफ़ करें, फिर माइग्रेट करें, फिर सत्यापित करें। यही क्रम भरोसे के साथ शुरू होने वाले सिस्टम और संदेह के साथ शुरू होने वाले सिस्टम के बीच का अंतर है।
गो-लाइव से पहले परीक्षण और स्वीकृति
इससे पहले कि कोई वास्तविक काम में सिस्टम को छुए, उसे आपके डेटा पर परीक्षण पास करना होगा, विक्रेता के डेमो डेटा पर नहीं। आप अपने वास्तविक व्यवसाय से परिदृश्य बनाते हैं — एक पूरा इनवॉइस, एक ख़रीद चक्र, एक महीने के अंत का क्लोज़िंग — और उन्हें सिस्टम में चलाकर देखते हैं कि वह सही परिणाम देता है।
फिर आता है स्वीकृति परीक्षण: आपकी अपनी टीम वे काम चलाती है जो वह रोज़ करेगी और पुष्टि करती है कि वे वैसे ही काम करते हैं जैसे उन्हें करना चाहिए। स्वीकृति परीक्षण औपचारिकता नहीं है; यह किसी कमी को असली ग्राहक के सामने संकट बनने से पहले पकड़ने का आख़िरी मौक़ा है।
गो-लाइव और हाइपरकेयर: क्रमिक, छलांग नहीं
गो-लाइव पर आपके सामने दो निर्णय होते हैं:
- चरणबद्ध या एक साथ (बिग-बैंग): बिग-बैंग लॉन्च एक ही दिन में सब कुछ चालू कर देता है, जोखिम को कई गुना बढ़ाता है और किसी भी गलती को पूरी कंपनी का संकट बना देता है। चरणबद्ध रोलआउट — एक बार में एक मॉड्यूल या एक शाखा — गलती को सीमित रखता है और कदम-दर-कदम भरोसा बनाता है। ज़्यादातर मामलों में चरणबद्ध तरीक़ा ज़्यादा सुरक्षित है; एक ही छलांग केवल सरल संचालन वाले छोटे व्यवसायों के लिए उपयुक्त है।
- हाइपरकेयर: गो-लाइव के बाद के पहले हफ़्ते सबसे नाज़ुक चरण होते हैं। गहन सहायता को टीम के पास रखें ताकि गलतियाँ तुरंत पकड़ी जाएँ और सवालों के जवाब तुरंत मिलें, जब तक सिस्टम स्थिर न हो जाए और लोग उस पर भरोसा न करने लगें। गो-लाइव अंतिम रेखा नहीं, बल्कि सबसे संवेदनशील चरण की शुरुआत है।
मानवीय पक्ष: स्वामी, प्रायोजन और परिवर्तन
अधिकांश परियोजनाएँ यहीं अटकती हैं — तकनीक में नहीं। कार्यान्वयन को तीन मानवीय स्तंभों की ज़रूरत होती है: अधिकार और समर्पित समय वाला एक आंतरिक स्वामी जो आपकी ओर से नेतृत्व करे, न कि कोई कर्मचारी जिस पर परियोजना को अतिरिक्त काम के रूप में डाल दिया गया हो; कार्यकारी प्रायोजन जो परियोजना को वास्तविक प्राथमिकता दे और विभागों के आर-पार के मामलों का फ़ैसला करे; और सचेत परिवर्तन प्रबंधन जो टीम को गो-लाइव से पहले तैयार करे, बाद में नहीं।
परिवर्तन प्रबंधन का अर्थ है लोगों को जल्दी शामिल करना ताकि वे ख़ुद को निर्णय का शिकार नहीं बल्कि उसका हिस्सा महसूस करें, केवल यह नहीं कि हम कैसे बदल रहे हैं बल्कि यह भी समझाना कि क्यों बदल रहे हैं, और प्रशिक्षण को एक बार की घटना के बजाय निरंतर बनाना। जिस सिस्टम को लोग अपनाते हैं वह सरल होने पर भी सफल होता है; जो उन पर थोपा जाता है उसका चुपचाप विरोध होता है, भले ही वह ज़्यादा शक्तिशाली हो।
Origami का दृष्टिकोण
हम एक टेक्नोलॉजी कंपनी हैं, लेकिन हमारे लिए कार्यान्वयन सॉफ़्टवेयर इंस्टॉल करना नहीं, बल्कि एक संगठित परियोजना है। हम किसी स्क्रीन को छूने से पहले खोज और प्रक्रिया ब्लूप्रिंट से शुरू करते हैं, डेटा माइग्रेशन को ऐसा चरण मानते हैं जो कॉपी नहीं करता बल्कि साफ़ और सत्यापित करता है, उस स्वीकृति परीक्षण पर ज़ोर देते हैं जिस पर आपकी टीम हस्ताक्षर करती है, और नज़दीकी हाइपरकेयर के साथ चरणों में लॉन्च करते हैं। और हम आंतरिक स्वामी, कार्यकारी प्रायोजन और परिवर्तन प्रबंधन को पहले दिन से योजना का हिस्सा बनाते हैं। हमारा लक्ष्य ऐसा सिस्टम है जो गो-लाइव के बाद भी जीवित रहे, न कि ऐसा जो हैंडओवर के दिन काम करे और उसके बाद छोड़ दिया जाए।
निष्कर्ष
सफल ERP कार्यान्वयन कोई घटना नहीं बल्कि चरणों वाली एक परियोजना है: प्रक्रियाओं का नक्शा बनाने वाली खोज, ले जाने से पहले साफ़ करने वाला माइग्रेशन, उपयोग करने वालों द्वारा हस्ताक्षरित स्वीकृति परीक्षण, हाइपरकेयर के बाद चरणबद्ध गो-लाइव, और इन सबसे ऊपर एक उपस्थित स्वामी, कार्यकारी प्रायोजन और परिवर्तन के लिए तैयार टीम। जो इन चरणों को क्रम से तय करता है, वह एक जीवित सिस्टम चलाता है; जो इनके ऊपर से छलांग लगाता है, वह एक टला हुआ संकट चलाता है। और इन सभी चरणों के आर-पार एक ऐसी शर्त खड़ी है जिसे सऊदी अरब में टाला नहीं जा सकता: अनुपालन। आठवें भाग में हम खोलेंगे कि हस्ताक्षर करने से पहले आपको किसी भी सिस्टम से क्या माँगना चाहिए — ई-इनवॉइसिंग, VAT और पूर्ण अरबी स्थानीयकरण — ऐड-ऑन के रूप में नहीं, बल्कि अनिवार्य आवश्यकताओं के रूप में।
स्रोत
- ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) — परीक्षण और गो-लाइव में ध्यान में रखने वाले दायित्व के रूप में ई-इनवॉइसिंग (Fatoora): https://zatca.gov.sa
- सऊदी डेटा और आर्टिफ़िशियल इंटेलिजेंस प्राधिकरण (SDAIA) — व्यक्तिगत डेटा संरक्षण क़ानून (PDPL) और माइग्रेशन के दौरान डेटा पर नियंत्रण: https://sdaia.gov.sa
- सऊदी विज़न 2030 — डिजिटल परिवर्तन और लघु एवं मध्यम उद्यमों का सशक्तिकरण: https://www.vision2030.gov.sa
सामान्य प्रश्न
ERP लागू करने का पहला कदम क्या है?
खोज चरण, इंस्टॉलेशन नहीं। आप हर विभाग के साथ बैठते हैं और यह दर्ज करते हैं कि वह वास्तव में कैसे काम करता है, हर प्रक्रिया के लिए एक तरीके पर सहमति बनाते हैं, और इसका परिणाम एक प्रक्रिया ब्लूप्रिंट होता है जो परियोजना का संविधान बन जाता है — जिससे हर विवाद सुलझाया जाता है और अनुकूलन की हर ज़रूरत को तौला जाता है।
मैं अपने पुराने डेटा को नए सिस्टम में सुरक्षित रूप से कैसे ले जाऊँ?
ले जाने से पहले साफ़ करें। दोहराए गए नाम, बिना मिलान वाले बैलेंस और बिना श्रेणी वाली मदों को स्रोत पर ही ठीक करें, फिर एक परीक्षण बैच माइग्रेट करें और उस पर भरोसा करने से पहले जाँचें कि कुल योग स्रोत से मेल खाते हैं। साफ़ सिस्टम में आने वाला गंदा डेटा गंदा ही रहता है।
क्या मुझे सिस्टम एक साथ लॉन्च करना चाहिए या चरणों में?
ज़्यादातर मामलों में चरणों में। एक साथ पूरा लॉन्च जोखिम को कई गुना बढ़ा देता है और किसी भी गलती को पूरी कंपनी का संकट बना देता है, जबकि चरणबद्ध लॉन्च गलती को सीमित रखता है और भरोसा बनाता है। एक ही छलांग केवल सरल संचालन वाले छोटे व्यवसायों के लिए उपयुक्त है, और उसके बाद गहन सहायता वाली हाइपरकेयर अवधि ज़रूर होनी चाहिए।
ERP कार्यान्वयन सबसे ज़्यादा कहाँ अटकता है?
मानवीय पक्ष पर, तकनीकी पक्ष पर नहीं। अधिकार वाले आंतरिक स्वामी का न होना, कमज़ोर कार्यकारी प्रायोजन और उपेक्षित परिवर्तन प्रबंधन सबसे अच्छे सिस्टम को भी गिरा देते हैं। जो टीम सिस्टम से आश्वस्त नहीं है, वह चुपके से अपनी स्प्रेडशीट पर लौट जाती है, और अंत में आपके पास दो अलग वास्तविकताएँ रह जाती हैं।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








