👨‍🎨 😈 🖖🏽 एक ईआरपी प्रणाली से दूसरे में प्रवासन 👩‍🏭 ♀️ 🕍

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

हाल के वर्षों में, हम इस तरह से कई दर्जन बार जा चुके हैं, और हमने ऐसा करने के लिए पहले से ही कम से कम दर्दनाक तरीका विकसित किया है।

कठिनाइयों

जिस दिन बाइसन ने आपके गांव को अपनी उपस्थिति से सम्मानित किया, वह आपके लिए जीवन का सबसे महत्वपूर्ण काम बन गया। लेकिन मेरे लिए यह मंगलवार था।
- बेयसन, स्ट्रीट फाइटर

संक्रमण प्रक्रिया अक्सर इस तथ्य से जटिल होती है कि ग्राहक के कई विशेष रूप से प्रभावशाली कर्मचारी पहली बार आतंक की स्थिति में हैं, क्योंकि उनके लिए यह उनके करियर में सबसे पहले प्रवासन की संभावना है। हमारे लिए, यह एक साधारण घटना है, जो एक नियम के रूप में, उसी परिदृश्य के अनुसार होती है।

जब कोई भी व्यक्ति दूसरे के लिए एक उत्पाद का आदान-प्रदान करता है, तो पहली बात यह है कि वह नोटिस करता है कि वह उससे लिया गया था और अभी तक उसे एहसास नहीं हुआ कि उसे क्या मिला । इसलिए, अक्सर पहली प्रतिक्रिया यह होती है: "क्या बकवास तुमने मुझे यहाँ खिसकाया - जैसा था वैसा ही करो।" व्यवहार में, हमारे पास एक ऐसी स्थिति थी जहां एक उपयोगकर्ता ने शिकायत की थी कि वह नई कार्रवाई के साथ सहज नहीं था, जो रूपों के बीच पांच बदलावों में पुरानी प्रणाली में किया गया था। लेकिन वह इस तरह के एक स्वचालितता के लिए पूर्ण था कि एक व्यक्ति के लिए यह वास्तव में दो नए, लेकिन बहुत सरल कार्यों को करने की तुलना में इसे करने के लिए पहले से तेज़ था।

एक और कठिनाई यह है कि संक्रमण के दौरान, ग्राहक अपनी दृष्टि से व्यावसायिक प्रक्रियाओं को बदलना पसंद करते हैं। इसे बहुत सावधानी के साथ व्यवहार किया जाना चाहिए, क्योंकि वर्तमान "जैसा है" प्रक्रियाओं को काम करने की गारंटी है। उत्पाद में एम्बेडेड प्रक्रियाएं, एक नियम के रूप में, काम भी करती हैं, क्योंकि वे अन्य ग्राहकों द्वारा उपयोग की जाती हैं। लेकिन सिद्धांत में नए आविष्कार सुंदर लग सकते हैं, लेकिन व्यवहार में वे एक तिपहिया में चलेंगे, जिसके कारण पूरी प्रक्रिया ठप हो सकती है।

परिदृश्यों

व्यवहार में, एक सिस्टम से दूसरे सिस्टम में जाने के लिए दो मुख्य परिदृश्य हैं:

एक शॉट

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

कागज पर सब कुछ सुंदर है। लेकिन व्यवहार में समस्याओं की कम से कम चार श्रेणियां हैं:

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

जब एक ही समय में संक्रमण के पहले दिन या सप्ताह में ये सभी चार समस्याएं होती हैं, तो व्यावसायिक नुकसान से बचा नहीं जा सकता है। इसलिए, ऐसी योजना केवल छोटी परियोजनाओं पर प्रभावी रूप से काम करती है। उदाहरण के लिए, जब उपयोगकर्ताओं की संख्या सौ से कम है और प्रक्रियाएँ महत्वपूर्ण नहीं हैं।

यह स्पष्ट है कि आप संक्रमण से तुरंत पहले प्रणाली के प्रशिक्षण और परीक्षण पर अधिक संसाधन खर्च कर सकते हैं, और फिर कम समस्याएं होंगी। लेकिन जीवन में, ग्राहक के कर्मचारी आमतौर पर इन प्रक्रियाओं को "स्लीवलेस" बताते हैं और "शायद" पर भरोसा करते हैं। या वे केवल गलत हैं, उम्मीद करते हैं कि एक निश्चित प्रक्रिया एक निश्चित सेटिंग में पैसा कमाने में सक्षम होगी, लेकिन वास्तव में, ऐसा लगेगा कि मामूली बारीकियों से सब कुछ कट जाएगा।

क्रमिक

इस दृष्टिकोण के साथ, सिस्टम को क्षैतिज रूप से (प्रक्रियाओं द्वारा) या लंबवत रूप से (उपयोगकर्ताओं द्वारा) भागों में विभाजित किया जाता है, जिन्हें एक दूसरे के साथ बारी-बारी से पेश किया जाता है। यह आपको उपरोक्त सभी समस्याओं को समय पर फैलाने और उन्हें हल करने की अनुमति देता है क्योंकि वे कम शक्ति प्राप्त करते हैं।

इसके अलावा, मैं दुकानों की एक खुदरा श्रृंखला के लिए खुले और मुक्त lsFusion मंच पर आधारित एक ERP प्रणाली के प्रवास की प्रक्रिया का वर्णन करूंगा , क्योंकि हम इस उद्योग में विशेषज्ञ हैं। लेकिन हमने अन्य क्षेत्रों के ग्राहकों के लिए एक ही सिद्धांत लागू किया।

डेटा रीडिंग

आमतौर पर, पुरानी प्रणाली का समर्थन करने वाली कंपनियों के लिए, उनके कार्यक्रम को बदलने और एक ग्राहक को खोने की खबर एक बड़ा झटका है। कुछ एक अपर्याप्त स्थिति में आते हैं और ग्राहक को तत्काल समर्थन बंद करने की धमकी देने लगते हैं। स्वाभाविक रूप से, यह कभी काम नहीं करता है, और कभी भी निर्णय को उलट नहीं सकता है। हालांकि, पुरानी प्रणाली का समर्थन करने वालों के साथ सहमत होना शायद ही संभव है कि वे टेबल प्रदान करते हैं जहां संक्रमण के लिए आवश्यक सभी डेटा संग्रहीत होते हैं।

सबसे पहले, आपको यह निर्धारित करने की आवश्यकता है कि कौन सी डीबीएमएस आवश्यक जानकारी संग्रहीत है और इसे कैसे एक्सेस करें। पिछले कुछ वर्षों में, हमें निम्नलिखित डीबीएमएस से निपटना पड़ा है जिसके साथ पुरानी प्रणालियों ने काम किया है:

प्रवेश। चूंकि प्लेटफ़ॉर्म जावा में लिखा गया है, इसलिए यह एक प्राचीन पुस्तकालय खोदना संभव था जो जानता था कि कैसे mdb से कनेक्ट किया जाए (हालांकि केवल पढ़ने के लिए)। इसने बहुत अजीब तरह से काम किया, क्योंकि फिल्टर के बावजूद यह पूरी तालिका को पढ़ता था, लेकिन फिर भी यह पर्याप्त था। हम भाग्यशाली थे कि ग्राहक की आईटी सेवा डेटाबेस संरचना को अच्छी तरह से जानती थी और हमें बताती है कि क्या और कहाँ संग्रहीत है।
MS SQL पुरानी प्रणाली एक्सपट्टा 2000 थी। हम परीक्षण प्रणाली तक पहुंच स्थापित कर चुके थे, जहां हमने GUI और SQL Profiler लॉन्च किया था। फिर हमने निर्देशिकाओं में बदलाव किया, और देखा कि Axapta क्या अनुरोध करता है। उनसे यह समझना आसान था कि वास्तव में यह या वह जानकारी कहाँ संग्रहीत है।
विजुअल फॉक्सप्रो यह सब सरल था, क्योंकि हमारी विरासत प्रणालियों से एक संक्रमण था और जानकारी प्राप्त करना मुश्किल नहीं था। एकमात्र कठिनाई एक जावा पुस्तकालय को खोजने में थी जो DBASE तालिकाओं के साथ नहीं, बल्कि Visual Foxpro प्रारूप के साथ काम कर सकती है।
ओरेकल। सुपरमैग बॉक्सेड प्रोग्राम से संक्रमण। हमने Axapta योजना के समान योजना के अनुसार काम किया: GUI और सबसे हाल के प्रश्नों के लिए SQL डेवलपर में क्वेरी। आधार संरचना और इंटरफेस निश्चित रूप से एक्सपट्टा की तुलना में बहुत सरल थे, इसलिए कोई बड़ी समस्या नहीं थी।
प्रगति / OpenEdge बॉक्सिंग गेस्टोरी कार्यक्रम से संक्रमण। यह देखते हुए कि DBMS, इसे हल्के ढंग से रखने के लिए, बिल्कुल भी लोकप्रिय नहीं है, हमें कोई प्रोफाइलर नहीं मिला। हालाँकि, पाठ फ़ाइलों में एक डंप था। इससे परीक्षण सर्वर के जीयूआई में जाना और स्क्रीन पर दिखाई देने वाले डेटा की खोज के लिए पाठ फ़ाइलों के माध्यम से खोज करना संभव हो गया। सौभाग्य से, इस DBMS की आधिकारिक वेबसाइट पर JDBC ड्राइवर को डाउनलोड करने, और SQL डेटाबेस में क्वेरी करने का अवसर है। तब यह तकनीक का मामला था।

ऐसे दृष्टिकोणों के लिए धन्यवाद, मुझे कभी भी पुरानी प्रणाली के डेवलपर्स की ओर मुड़ना नहीं पड़ा, जिससे ग्राहकों के खर्चों में काफी बचत हुई, क्योंकि आमतौर पर वे सहयोग के लिए बड़ी मात्रा में धनराशि निकालते थे।

मास्टर डेटा

यह सब मास्टर डेटा आयात करने के साथ शुरू होता है। विशेष रूप से, खुदरा व्यापार के लिए, माल, माल, ठेकेदारों और दुकानों के समूहों की निर्देशिकाओं का आयात सबसे पहले महसूस किया जाता है। क्रमिक संक्रमण के साथ, मास्टर डेटा आयात करने के लिए दो दृष्टिकोण हैं:

एक बार का डेटा आयात, और फिर पुराने और नए सिस्टम में दोहरी प्रविष्टि।
पुराने से नए सिस्टम में डेटा की निरंतर वृद्धि अद्यतन।

ऐसे मामले हैं जब पहले दृष्टिकोण का उपयोग किया जाता है, लेकिन यह बहुत समय लेने वाली है और त्रुटियों की संभावना के साथ मानव कारक के लिए अतिसंवेदनशील है। इसलिए, हम हमेशा केवल दूसरे विकल्प का उपयोग करते हैं।

आदर्श रूप से, पुरानी प्रणाली परिवर्तनों को जमा कर सकती है और किसी भी तरह से संवाद कर सकती है कि इसे फिर से शुरू करने की आवश्यकता है। लेकिन आम तौर पर कोई भी पुरानी प्रणाली में कुछ भी नहीं बदलेगा या संशोधित करेगा। इसलिए, हमारे द्वारा उपयोग की जाने वाली एकमात्र कार्य योजना इस प्रकार है:

पुरानी प्रणाली की निर्देशिका के लिए एक अनुरोध है, जो इससे सभी डेटा पढ़ता है।
नई प्रणाली में वर्तमान के साथ रीड डेटा की तुलना की जाती है और परिवर्तनों का पता लगाया जाता है।
नई प्रणाली के लिए एकल लेनदेन में परिवर्तन लिखे गए हैं।

उत्पाद निर्देशिका आयात करने के लिए मंच पर कोड इस तरह दिखेगा:

importItems ' ' {
NEWSESSION {
LOCAL file = FILE ();
//
READ 'jdbc:sqlserver://localhost;databaseName=items;User=import;Password=password@SELECT id, name FROM items' TO file;

LOCAL id = STRING [ 20 ] ( INTEGER );
LOCAL name = ISTRING [ 100 ] ( INTEGER );
//
IMPORT TABLE FROM file() TO id, name;

//
FOR id( INTEGER i) AND NOT item(id(i)) NEW b = Item DO {
id(b) <- id(i);
}

//
FOR id(Item b) = id( INTEGER i) DO {
name(b) <- name(i);
}

// ,
DELETE Item b WHERE b IS Item AND NOT [ GROUP SUM 1 BY id( INTEGER i)](id(b));

APPLY ;
}
}

यह निम्नानुसार काम करेगा:

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

वास्तव में, लॉन्च के समय यह क्रिया पूरी तरह से पुरानी और नई निर्देशिका को सिंक्रनाइज़ करती है। यह किसी भी वृद्धिशील जानकारी को संग्रहीत नहीं करता है, इसलिए इसे किसी भी समय फिर से शुरू किया जा सकता है, भले ही पिछला एक्सचेंज त्रुटियों के साथ पूरा हो गया हो।

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

अधिकतर, हम उपयोगकर्ता को मैन्युअल रूप से एक्सचेंज शुरू करने का अवसर प्रदान करते हुए, एक घंटे में एक बार पुरानी प्रणाली के साथ सभी निर्देशिकाओं को सिंक्रनाइज़ करने के लिए कार्रवाई को सक्षम करते हैं।

प्रक्रिया

रिटेल में, हम आमतौर पर अनुवाद प्रक्रिया को दुकानों के बीच और साथ-साथ क्षैतिज रूप से स्टोर प्रक्रियाओं से कार्यालय प्रक्रियाओं तक विभाजित करते हैं।

पहला चरण एक स्टोर चुनना है जहां नई प्रणाली में स्थानांतरण शुरू हो जाएगा। मौजूदा शेष राशि को आयात करता है और पुरानी व्यवस्था से आने वाली दस्तावेजों के रूप में संबंधित मात्रा और कीमतों के साथ कीमतों को स्टोर करता है:

स्रोत कोड उदाहरण

importInventory ' ' {
NEWSESSION {
LOCAL file = FILE ();
//
READ 'jdbc:sqlserver://localhost;databaseName=items;User=import;Password=password@SELECT idSku, quantity, idDoc, dateDoc, idDetail FROM inventory' TO file;

LOCAL idSku = STRING [ 20 ] ( INTEGER );
LOCAL quantity = NUMERIC [ 16 , 3 ] ( INTEGER );
// idDoc, dateDoc idDetail -
// ,
LOCAL idDoc = STRING [ 20 ] ( INTEGER );
LOCAL dateDoc = DATE ( INTEGER );
LOCAL idDetail = STRING [ 20 ] ( INTEGER );
//
IMPORT TABLE FROM file() TO idSku, quantity, idDoc, dateDoc, idDetail;

//
FOR [ GROUP SUM 1 BY idDoc( INTEGER i)](id) AND NOT receipt(id) NEW r = Receipt DO {
id(r) <- id;
}

//
FOR INTEGER i = [ GROUP MIN INTEGER ii BY idDoc(ii)](id) AND id(Receipt r) = id DO {
date(r) <- dateDoc(i);
}

// ,
FOR idDetail( INTEGER i) AND NOT receiptDetail(idDetail(i)) NEW d = ReceiptDetail DO {
id(d) <- idDetail(i);
}


//
FOR id(ReceiptDetail d) = idDetail( INTEGER i) DO {
receipt(d) <- receipt(idDoc(i));
quantity(d) <- quantity(i);
}

// ,
DELETE Receipt r WHERE id(r) AND NOT [ GROUP SUM 1 BY idDoc( INTEGER i)](id(r));
DELETE ReceiptDetail d WHERE id(d) AND NOT [ GROUP SUM 1 BY idDetail( INTEGER i)](id(d));

//
APPLY ;
}
}

स्टोर की शुरुआत से कुछ हफ्ते पहले, पीओएस सिस्टम से कार्यान्वयन का आयात जुड़ा हुआ है। यह आवश्यक है ताकि काम के पहले दिनों में आदेशों के गठन के लिए ऐतिहासिक डेटा हो।

बहुत बार, स्वयं की उत्पादन की प्रक्रिया को मुख्य प्रक्रियाओं की तुलना में थोड़ी देर बाद स्थानांतरित किया जाता है। इस मामले में, कच्चे माल की आवाजाही पर दस्तावेजों की पुरानी प्रणाली में उतारना और वहां से तैयार उत्पादों के आयात को लागू किया जाता है।

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

उपरोक्त वर्णित सभी समस्याओं को पहले स्टोर पर पहचाना और हल किया जाता है, लगभग दो सप्ताह के बाद एक और 2-3 स्टोर स्थानांतरित किए जाते हैं। समस्याओं की पहचान करने और उन्हें ठीक करने का एक पुन: उपयोग। और फिर ग्राहक के ग्राहक सहायता सेवा के संसाधनों के आधार पर अन्य सभी का बहुत जल्दी अनुवाद किया जाता है। यह सब समय, मास्टर डेटा को पुराने सिस्टम में दर्ज करना जारी रखता है ताकि स्टोर पुराने सिस्टम पर कार्य कर सकें।

फिर, जब सभी दुकानों को स्थानांतरित कर दिया जाता है, तो या तो धीरे-धीरे या उनमें से सभी तुरंत पुरानी प्रणाली से आयात बंद कर देते हैं, और उपयोगकर्ता नई प्रणाली में मास्टर डेटा दर्ज करना शुरू करते हैं।

पुरानी और नई प्रणालियों की सारांश जानकारी या तो लेखांकन या बीआई प्रणाली में प्राप्त की जाती है, जहां दोनों प्रणालियों को एक ही समय में अपलोड किया जाता है। वहां आप अंतराल के लिए सारांश रिपोर्ट प्राप्त कर सकते हैं, जिसमें पुराने और नए सिस्टम में समय शामिल है।

निष्कर्ष

एक प्रणाली से दूसरे में संक्रमण की स्पष्ट जटिलता के बावजूद, कई दर्जन बार इस रास्ते पर चलने के बाद, आप समझते हैं कि एक डिबगड स्कीम के साथ, सब कुछ वास्तव में इतना डरावना नहीं है। इस तथ्य के साथ और अधिक समस्याएं उत्पन्न होती हैं कि क्लाइंट के अधिकांश कर्मचारी काफी रूढ़िवादी हैं और थोड़े से अवसर पर, "जिस तरह से" ऐसा करने की मांग की गई थी। और यहां यह बहुत महत्वपूर्ण है कि ग्राहक के पास पर्याप्त अधिकार वाला व्यक्ति है जो पुरानी और नई प्रक्रियाओं की तुलना कर सकता है, यह निर्धारित कर सकता है कि कौन से अधिक इष्टतम हैं और कर्मचारियों को "ब्रेक" करने में सक्षम हैं। या "जैसा था" योजना के अनुसार प्रक्रिया को संशोधित करें, अगर यह दूसरे तरीके से घूमता है।

एक ईआरपी प्रणाली से दूसरे में प्रवासन