ERP इम्प्लीमेंटेशन में कितना समय लगता है? वास्तविक समयसीमाएँ

इस बात का चरण-दर-चरण जवाब कि एक ERP प्रोजेक्ट में कितना समय लगता है, वे कौन सी बातें हैं जो इसे लंबा बनाती हैं, और एक ऐसे अकाउंटिंग कोर की तुलनात्मक समयसीमा जिसे आप API के ज़रिए इंटीग्रेट करते हैं।

Nordlet Team · 2 अक्टूबर 2026 · 10 मिनट पढ़ने में

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

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

नौ चरण और प्रत्येक को क्या चीज़ संचालित करती है

चरण	विशिष्ट अवधि	लंबाई को प्रभावित करने वाले कारक
चयन (Selection)	1–3 महीने	शॉर्टलिस्ट किए गए वेंडर की संख्या, डेमो राउंड, रेफरेंस कॉल, प्रोक्योरमेंट नियम
डिज़ाइन	2–8 सप्ताह	कितने प्रक्रियाओं को मैप किया जाना है, क्या टीम उन पर सहमत है, वेंडर के स्टैंडर्ड फ्लो को ज्यों का त्यों कितना स्वीकार किया जाता है
डेटा माइग्रेशन	4–16 सप्ताह	मास्टर डेटा की गुणवत्ता, इतिहास के कितने साल स्थानांतरित किए जाते हैं, स्रोत प्रणालियों (source systems) की संख्या
कॉन्फ़िगरेशन	4–12 सप्ताह	एंटिटी की संख्या, चार्ट ऑफ़ अकाउंट्स, देश, टैक्स व्यवस्था, अप्रूवल फ्लो
इंटीग्रेशन	4–20 सप्ताह	कनेक्ट करने के लिए सिस्टम की गिनती (बैंक, पेroll, ई-कॉमर्स, CRM, वेयरहाउस), प्रत्येक पक्ष के API की गुणवत्ता
टेस्टिंग	3–8 सप्ताह	एंड-टू-एंड परिदृश्यों की संख्या, क्या टेस्ट डेटा यथार्थवादी है, पहला पास कितनी कमियों (defects) का पता लगाता है
ट्रेनिंग	2–6 सप्ताह	कर्मचारियों की संख्या, भूमिका की विविधता, पुरानी प्रक्रिया से नई प्रक्रिया कितनी अलग है
गो-लाइव (Go-live)	1–2 सप्ताह	कटओवर विधि (बिग-बैन या चरणबद्ध), अवधि के अंत (period end) के मुकाबले समय
हाइपरकेयर (Hypercare)	4–12 सप्ताह	गो-लाइव के समय खुली कमियों की गिनती, पहला मंथ-एंड क्लोज़, नए सिस्टम से पहली VAT रिटर्न

व्यवहार में ये चरण एक-दूसरे पर ओवरलैप होते हैं। कॉन्फ़िगरेशन अभी चल ही रहा होता है कि इंटीग्रेशन शुरू हो जाता है; ट्रेनिंग अक्सर टेस्टिंग के साथ ओवरलैप होती है। एक यथार्थवादी योजना कॉलम का योग नहीं होती है, लेकिन क्रिटिकल पाथ (critical path) आमतौर पर डेटा माइग्रेशन और इंटीग्रेशन से होकर गुजरता है, और यही वो दो हिस्से हैं जहाँ से अधिकांश देरी होती है।

क्या चीज़ इसे लंबा बनाती है

कस्टमराइज़ेशन। वेंडर के स्टैंडर्ड व्यवहार में किए जाने वाले हर बदलाव को निर्दिष्ट, निर्मित, परिक्षित, प्रलेखित (documented) किया जाना चाहिए, और फिर भविष्य के हर अपग्रेड पर दोबारा टेस्ट किया जाना चाहिए। जो प्रोजेक्ट 90% फ़्लो के लिए स्टैंडर्ड प्रक्रिया को स्वीकार करता है और बाकी को कस्टमराइज़ करता है, वह पूरा हो जाता है; जो प्रोजेक्ट पुराने सिस्टम की स्क्रीन को हूबहू दोहराने से शुरू होता है, वह आमतौर पर पूरा नहीं होता है।

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

कई एंटिटी (Multiple entities)। प्रत्येक लीगल एंटिटी को अपने चार्ट, नंबरिंग, VAT रजिस्ट्रेशन, बैंक खातों और पीरियड क्लोज़ की आवश्यकता होती है। उनके बीच के इंटरकंपनी फ़्लो को अपने खुद के डिज़ाइन की आवश्यकता होती है। कॉन्फ़िगरेशन चरण को एंटिटी की संख्या से गुणा करें, और फिर ऊपर से कंसोलिडेशन डिज़ाइन जोड़ें।

बहु-देशीय टैक्स (Multi-country tax)। कई EU सदस्य राज्यों में सामान बेचने वाली कंपनी को नए सिस्टम में पहले रिटर्न की देयता से पहले प्लेस-ऑफ़-सप्लाई के नियमों, रिवर्स चार्ज, OSS रिपोर्टिंग और स्थानीय फाइलिंग फॉर्मेट को सही करना होगा। यदि किसी देश के लिए वेंडर का लोकलाइज़ेशन नेटिव के बजाय पार्टनर द्वारा बनाया गया है, तो उस पार्टनर की उपलब्धता क्रिटिकल पाथ का हिस्सा बन जाती है।

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

स्कोप से पहले तय की गई गो-लाइव तिथि। जब कोई तिथि राजनीतिक कारणों से तय की जाती है और स्कोप का पता बाद में चलता है, तो प्रोजेक्ट या तो टेस्टिंग काट देता है या तिथि आगे बढ़ा देता है। दोनों ही महंगे साबित होते हैं।

क्या चीज़ इसे छोटा बनाती है

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

एक अलग शेड्यूल: API-फर्स्ट अकाउंटिंग कोर

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

Nordlet के साथ यह कैसा दिखता है, इसे वादे के रूप में नहीं बल्कि उत्पाद आज जो करता है उसके रूप में प्रस्तुत किया गया है:

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

पहले से पाँचवें दिन तक: पहला कार्यशील फ़्लो (working flow)। एक पार्टनर बनाएं, एक चालान (invoice) बनाएं, उसे जारी करें, भुगतान प्राप्त करें, जारी करने से उत्पन्न जर्नल एंट्री को पढ़ें। प्रत्येक ऑपरेशन एक JSON बॉडी के साथ POST /v1/{module}/{resource}/{action> कॉल है, और नौ भाषाओं के लिए टाइप किए गए SDK मौजूद हैं, इसलिए पहला फ़्लो कोड की कुछ दर्जन लाइनें हैं। रीट्राय (Retries) सुरक्षित हैं क्योंकि एक Idempotency-Key हेडर दूसरा चालान बनाने के बजाय संग्रहीत प्रतिक्रिया को दोबारा चलाता है।

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

दूसरे से चौथे सप्ताह तक: बाकी का इंटीग्रेशन। PSD2 कनेक्शन के माध्यम से बैंक फीड, camt.053 स्टेटमेंट इंपोर्ट, Stripe एक्सपोर्ट, वेबहुक जैसे कि sale_invoice.paid ताकि आपका सिस्टम पोलिंग के बजाय घटनाओं पर प्रतिक्रिया दे। प्रत्येक टुकड़ा एक अलग एंडपॉइंट है और इसे समानांतर रूप से एक अलग डेवलपर द्वारा बनाया जा सकता है।

अनुपालन (Compliance): पहले से पंजीकृत। सीमा पार बिक्री (cross-border sale) के VAT उपचार को EU VAT इंजन द्वारा हल किया जाता है, और कंपनी के देश के लिए फाइलिंग कैलेंडर अंतर्निहित नियमों से भरा जाता है। फाइलिंग सपोर्ट टेबल सभी 30 देशों के लिए सूचीबद्ध करती है कि Nordlet किन समयसीमाओं को खुद फाइल करता है, किसके लिए फाइल बनाता है, और किसे हाथ से दर्ज किया जाता है। इनमें से कोई भी प्रोजेक्ट का काम नहीं है।

परीक्षण के रूप में पीरियड क्लोज़। पहला मंथ-एंड क्लोज़ वह जगह है जहाँ एक ERP प्रोजेक्ट को पता चलता है कि यह काम करता है या नहीं। एक अपरिवर्तनीय लेज़र (immutable ledger) और पीरियड लॉकिंग के साथ, लॉक किए गए महीने में तारीख़ वाली पोस्टिंग को 409 के साथ अस्वीकार कर दिया जाता है, इसलिए क्लोज़ को अनुशासन के बजाय सिस्टम द्वारा लागू किया जाता है, और इंटीग्रेशन की जो कमियाँ हाइपरकेयर में मिलतीं, वे इसके बजाय सैंडबॉक्स में सतह पर आ जाती हैं।

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

अपने खुद के प्रोजेक्ट का अनुमान कैसे लगाएं

एंटिटी, देशों और VAT रजिस्ट्रेशन की गिनती करें। पारंपरिक ERP में प्रत्येक कॉन्फ़िगरेशन का काम होता है और API-फर्स्ट में एक कंपनी रिकॉर्ड।
इंटीग्रेशन की गिनती करें और साइन करने से पहले प्रत्येक सिस्टम के API की जाँच करें। केवल-फ़ाइल वाला इंटरफ़ेस इंटीग्रेशन के अनुमान को लगभग दोगुना कर देता है।
तय करें कि कितना इतिहास माइग्रेट करना है। ओपनिंग बैलेंस और ओपन आइटम हफ्तों का काम है; पूर्ण बहु-वर्षीय इतिहास महीनों का काम है।
पीरियड कैलेंडर से कटओवर तिथि तय करें, न कि इसके विपरीत। रिकॉन्सिलिएटेड क्लोजिंग बैलेंस के साथ वर्ष-अंत या तिमाही-अंत की सीमा सबसे सस्ती कटओवर है।
मान लें कि पहले क्लोज़ में सामान्य से दोगुना समय लगता है, और नए सिस्टम से पहली VAT रिटर्न और पहले पेरोल रन के लिए हाइपरकेयर का बजट रखें।
प्रोजेक्ट शुरू होने से पहले स्वीकृति परीक्षण लिखें: दस्तावेजों, रिपोर्टों और फाइलिंग की सूची जो नए सिस्टम से बंद हुए पहले महीने के लिए सही ढंग से बाहर आनी चाहिए। प्री-प्रोडक्शन टेस्ट प्लान अकाउंटिंग वाले हिस्से के लिए एक टेम्पलेट है।

FAQ

क्या किसी ERP इम्प्लीमेंटेशन में तीन महीने से कम समय लग सकता है?

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

कौन सा चरण सबसे अक्सर पिछड़ता है?

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

क्या हमें पूरा इतिहास माइग्रेट करना चाहिए या केवल ओपनिंग बैलेंस?

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

क्या चरणबद्ध रोलआउट (phased rollout) बिग-बैन कटओवर से तेज़ होता है?

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

API-फर्स्ट उत्पाद के लिए "इम्प्लीमेंटेशन" कैसे अलग है?

स्क्रीन-दर-स्क्रीन कॉन्फ़िगरेशन प्रोजेक्ट जैसा कुछ नहीं होता है। काम इंटीग्रेशन और माइग्रेशन का है, जो डेवलपर्स द्वारा सैंडबॉक्स के खिलाफ किया जाता है, और अनुपालन परत (VAT नियम, फाइलिंग फॉर्मेट, कैलेंडर) उत्पाद के साथ आती है। इसका ट्रेड-ऑफ यह है कि आपके पक्ष का कोई व्यक्ति कोड लिखता है।