90 दिनों का ERP roadmap: भरोसेमंद data, मंज़ूर चरणों में शुरुआत

शुक्रवार की दोपहर है। ऑनलाइन दुकान में सामान उपलब्ध दिख रहा है, लेकिन warehouse की sheet में stock खत्म है। ग्राहक इंतज़ार कर रहा है और दो सहकर्मी exports मिला रहे हैं। यह समझाने के लिए बनाया गया उदाहरण है, किसी ग्राहक की असली case study नहीं। एक ही तथ्य के कई अलग संस्करण समस्या पैदा कर रहे हैं।

एक और dashboard लगाने से मतभेद नहीं मिटेगा। पहले तय करें कि हर record की ज़िम्मेदारी किसकी है, बदलाव दूसरे system तक कैसे पहुँचेंगे और message देर से आए तो क्या होगा। ERP का उद्देश्य भरोसेमंद business process बनाना है।

2026 की यह guide लगभग 90 दिनों में सीमित scope वाला पहला ERP rollout तैयार करने का उदाहरण है, delivery guarantee नहीं। कई legal entities, जटिल manufacturing, संवेदनशील data या स्थानीय payroll rules के लिए अधिक समय लग सकता है।

अलग-अलग टूल्स की असली लागत कहाँ छिपी है

पाँच software की लाइसेंस फ़ीस आमतौर पर असली समस्या नहीं होती। असली लागत उस काम में छिपी है जो इन टूल्स के बीच होता है। यह किसी invoice में नहीं दिखता, इसलिए लगभग सभी इसे कम आँकते हैं। आमतौर पर तस्वीर कुछ ऐसी होती है:

• एक ही data बार-बार टाइप करना। महीने के आख़िर में स्टोर से order एक्सपोर्ट करके accounting में डाले जाते हैं। हर मैन्युअल कदम पर कोई दशमलव या discount छूट जाने का ख़तरा रहता है।
• stock का हिसाब न मिलना। ऑनलाइन स्टोर, POS और गोदाम की शीट — तीनों में तीन अलग आँकड़े। नतीजा: ऑनलाइन वह माल बिक जाता है जो है ही नहीं, या शेल्फ़ पर पड़ा माल ऑनलाइन "आउट ऑफ़ stock" दिखता है।
• नज़र से ओझल पैसा। COD का पैसा कई दिन courier के पास पड़ा रहता है। उनकी settlement फ़ाइल को order से मिलाना पूरी तरह हाथ का काम है, और जो एंट्री मेल नहीं खातीं वे चुपचाप घाटे में चली जाती हैं।
• सैलरी का अलग टापू। हाज़िरी एक जगह, छुट्टियाँ दूसरी जगह, सैलरी एक शीट में। payroll चलने के बाद भी वह कभी सही journal entry बनकर खाते में नहीं पहुँचता।
• reportों में आपस में मेल नहीं। स्टोर dashboard की sales accounting के रेवेन्यू से कभी मेल नहीं खाती, इसलिए हर मीटिंग "कौन-सा आँकड़ा सही है" की बहस से शुरू होती है।

खरीदने से पहले coordination का काम मापें। मान लीजिए, चार लोग 20 कार्यदिवस तक रोज़ आधा घंटा exports मिलाते हैं: 4 × 0.5 × 20 = 40 staff-hours। यह केवल गणना का उदाहरण है, industry benchmark या सभी 40 घंटे बचने का वादा नहीं।

सात संकेत कि मौजूदा टूल अब काफ़ी नहीं

ERP की ज़रूरत किसी तय टर्नओवर पर पहुँचने से नहीं होती। ज़रूरत तब होती है जब तालमेल बिठाने की लागत बदलाव की लागत से ज़्यादा हो जाए। मैं ये संकेत देखता हूँ:

1. महीने की क्लोज़िंग में पाँच वर्किंग डे से ज़्यादा लगते हैं, और ज़्यादातर समय मिलान में जाता है।
2. पिछली तिमाही में कम से कम एक बार stock से ज़्यादा sales हुई, क्योंकि दो channel एक ही stock से बेच रहे थे और एक-दूसरे को पता नहीं था।
3. एक ही व्यक्ति पूरा "integration" है। वह छुट्टी पर जाए तो invoice, सैलरी या courier का हिसाब — सब रुक जाता है।
4. आसान सवालों के जवाब जल्दी नहीं मिलते। जैसे, "इस महीने किस product पर कितना मुनाफ़ा हुआ?" या "courier के पास अभी कितना COD पैसा अटका है?"
5. ग्राहक की जानकारी बिखरी हुई है। order, सपोर्ट टिकट और लॉयल्टी पॉइंट अलग-अलग टूल में हैं, इसलिए कोई भी ग्राहक की पूरी तस्वीर नहीं देख पाता।
6. हर नया channel एक नई परेशानी। दूसरा outlet या नया सेल्स channel खोलने का मतलब है एक और टूल और एक्सपोर्ट का एक और दौर।
7. audit के नाम से घबराहट होती है। किसने, कब कोई क़ीमत, सैलरी या stock बदला — यह दिखाने का कोई तरीक़ा नहीं।

ये संकेत जाँच शुरू करने के लिए हैं, तुरंत software खरीदने के लिए नहीं। एक गंभीर control failure कई छोटी परेशानियों से महत्वपूर्ण हो सकता है। पूरा system बदलने के साथ targeted integration और process improvement की तुलना भी करें।

"integrated" का असली मतलब

एक login होना integration नहीं है। हर business fact का स्पष्ट owner होना चाहिए: stock movements का Inventory और posted journals का Accounting। दूसरे modules नियंत्रित read models रख सकते हैं, पर उन्हें अलग master records नहीं बनना चाहिए।

Events integration का एक तरीका हैं, शुद्धता की guarantee नहीं। Retry, duplicate detection, reconciliation और failure handling अलग से बनानी होगी। Audit trail के लिए पहचान, समय, retention और access controls भी ज़रूरी हैं; event bus अकेला यह नहीं देता।

• हर तथ्य का एक owner, स्पष्ट interfaces और reconciliation।
• Dependencies और पूरा workflow जाँचकर modules जोड़ें।
• Audit records, approvals और recovery स्पष्ट रूप से बनाएँ; ये अपने-आप नहीं आते।

order से पैसा हाथ में आने तक, कदम दर कदम

एक sales को integrated system में शुरू से आख़िर तक देखिए, फ़र्क़ साफ़ दिख जाएगा:

Business checkpoint	कौन-सा evidence रखें
Order स्वीकार	Order और लागू commercial rules जाँचें।
Stock reserve	Quantity रोकें; cancel या expiry पर छोड़ें।
Payment record	Authorised, captured, failed, refunded और unpaid अलग रखें।
Fulfilment पुष्टि	क्या भेजा, पहुँचा और वापस आया, दर्ज करें।
Accounting posting	Finance द्वारा मंज़ूर recognition, tax और receivable rules लागू करें।
Settlement मिलान	Orders, fees और adjustments से payment/courier remittance मिलाएँ।

यह table business checklist है, सबके लिए तय accounting sequence नहीं। Payment exceptions, refund approvals और stock differences में लोगों की भूमिका रहती है। Order acceptance, delivery, revenue recognition और cash settlement अलग घटनाएँ हैं; finance team इनके नियम मंज़ूर करेगी।

90 दिनों में चरणबद्ध ERP roadmap

छोटे और जुड़े हुए scope में एक साथ cutover सही हो सकता है, पर जोखिम एक जगह जमा होता है। चरणों में rollout से शुरुआती असर सीमित रहता है, लेकिन अस्थायी integration और reconciliation का काम बढ़ता है। Dependencies और support क्षमता देखकर रास्ता चुनें।

नीचे के समय planning windows हैं। एक location या शुरू से अंत तक एक process से शुरुआत करें। तय evidence मिलने पर ही अगला चरण लें; तारीख निकल जाना acceptance test नहीं है।

चरण 0 — data audit (हफ़्ते 1–2)

कुछ भी सेटअप करने से पहले एक सूची बनाइए: कौन-कौन से टूल चल रहे हैं, किसकी ज़िम्मेदारी किसके पास है, और किसमें कौन-सा data है। फिर हर तरह के data के लिए तय कीजिए कि मूल रिकॉर्ड कौन-सा माना जाएगा — product, ग्राहक, supplier, कर्मचारी। साफ़ दिखने वाली गड़बड़ियाँ अभी ठीक कीजिए: एक ही ग्राहक दो बार, एक SKU पर दो अलग product, एक ही supplier तीन अलग स्पेलिंग में।

नतीजा: एक पेज का माइग्रेशन मैप, जिसमें लिखा हो कि नए system में हर अहम आँकड़ा कहाँ रहेगा।

चरण 1 — catalog और stock (हफ़्ते 3–5)

product, वेरिएंट और बारकोड डालिए। location तय कीजिए: गोदाम, outlet और रास्ते में मौजूद माल। शुरुआती stock लागत के साथ दर्ज कीजिए, क्योंकि आगे मुनाफ़े की report का मतलब इसी लागत से बनता है। चरण के आख़िर में फ़िज़िकल गिनती करके system से मिलान कीजिए।

नतीजा: stock का एक ही आँकड़ा, जिसे हर channel पढ़ता है।

चरण 2 — order और पैसा (हफ़्ते 6–8)

Order, payment, refund, tax और settlement को शुरू से अंत तक जाँचें। Finance opening balances और posting mappings मंज़ूर करे। Parallel comparison में एक ledger को आधिकारिक रखें और दूसरे system को उससे मिलाएँ।

नतीजा: महीने की क्लोज़िंग system से, स्प्रेडशीट से नहीं।

चरण 3 — लोग और payroll (हफ़्ते 9–11)

Payroll तभी जोड़ें जब स्थानीय नियम, privacy controls और ज़िम्मेदारियाँ तैयार हों। Leave, overtime, deductions, corrections और journal समेत पूरा pay cycle तुलना करें। ज़्यादा समय लगे तो नियंत्रित integration बनाए रखें; day 90 में payroll ठूँसना ज़रूरी नहीं।

नतीजा: हाज़िरी और छुट्टी से जुड़ा, एक बार में पूरा होने वाला payroll।

चरण 4 — report और automation (हफ़्ते 12–13)

अब data भरोसेमंद है, तो तय कीजिए कि किस भूमिका वाले व्यक्ति को रोज़ सुबह कौन-से आँकड़े दिखने चाहिए। stock कम होने के alert, channel और outlet के हिसाब से रोज़ की sales का सार, और refund व परचेज़ order के लिए अप्रूवल का क्रम चालू कीजिए। अगर AI असिस्टेंट इस्तेमाल करते हैं, तो शुरुआत में उसे सिर्फ़ देखने की अनुमति दीजिए; कोई भी काम वह तभी करे जब कोई ज़िम्मेदार व्यक्ति मंज़ूरी दे।

नतीजा: ऐसे data पर फ़ैसले, जिस पर सबको भरोसा है।

Phase gate: process owner reconciled data, वास्तविक exception tests, trained operators और support plan देखकर मंज़ूरी दे। एक शांत सप्ताह उपयोगी है, लेकिन month-end close या refund जैसे कम होने वाले महत्वपूर्ण काम के test की जगह नहीं ले सकता।

Go-live से पहले मुश्किल दिन की तैयारी करें

वास्तविक operators के साथ एक order, partial delivery, return और failed settlement की rehearsal करें। दोबारा आए webhook और provider outage को जाँचें। Retry, adjustment approval तथा salary या customer data देखने की अनुमति तय करें। Cutover freeze, final export, reconciliation totals, decision owner और rollback trigger लिखें। नए system में transactions आ चुके हों तो पुराने system पर लौटते समय उन नए records का नियंत्रित मिलान भी करना होगा; केवल पुराना backup restore करना सुरक्षित rollback नहीं है।

ख़ुद देखिए: आपस में जुड़ा बैक ऑफ़िस

इस छोटे वीडियो में ऊपर बताई प्रक्रिया का accounting वाला हिस्सा दिखाया गया है: चार्ट ऑफ़ अकाउंट्स, कारोबारी घटनाओं से अपने-आप बनी journal entry, और उनसे बनी reportें।

पाँच ग़लतियाँ जो ERP project डुबो देती हैं

1. बिखरा हुआ data जस का तस ले आना

Business need और लागू retention obligations के अनुसार migration scope चुनें। Opening quantities, values और balances मिलाएँ; आवश्यक history खोजने योग्य रखें। सिर्फ़ पुराना होने पर record न मिटाएँ। Backup पर निर्भर होने से पहले restore जाँचें।

2. इस्तेमाल से पहले ही कस्टमाइज़ करना

Customisation से पहले standard workflow आज़माएँ, लेकिन वास्तविक legal, safety या operational gaps लिखें। Owner और मापने योग्य लाभ के आधार पर बदलाव चुनें; अधिकांश requirements एक महीने में गायब हो जाएँगी, ऐसा तय नियम नहीं है।

3. module का कोई ज़िम्मेदार नहीं

हर module के लिए कंपनी के अंदर एक व्यक्ति चाहिए जो तय करे कि उसे कैसे इस्तेमाल करना है — inventory के लिए एक, accounting के लिए एक, HR के लिए एक। ज़िम्मेदार न हो तो सेटअप के फ़ैसले वही लेता है जो सबसे ऊँची आवाज़ में बोलता है।

4. ज़मीनी स्टाफ़ की ट्रेनिंग छोड़ देना

मैनेजरों को demo मिलता है, और कैशियर या पिकर्स को एक छपा हुआ पन्ना। फिर काउंटर स्टाफ़ अपने जुगाड़ निकाल लेता है और stock का हिसाब बिगड़ जाता है। जो लोग system सबसे ज़्यादा इस्तेमाल करेंगे, उन्हें उनकी अपनी screen पर ट्रेनिंग दीजिए।

5. लॉन्च को ही मंज़िल मान लेना

लॉन्च असल काम की शुरुआत है। 30 दिनों का स्थिरता वाला समय रखिए: रोज़ 15 मिनट की छोटी मीटिंग, सबको दिखने वाली समस्याओं की एक सूची, और हर समस्या का एक तय ज़िम्मेदार।

नापिए: KPI जो साबित करें कि ERP काम आया

पहले baseline दर्ज करें और process owners के साथ targets तय करें। नीचे की worksheet बताती है कि क्या मापना है; इसमें गढ़े हुए before–after benchmarks नहीं हैं।

माप	परिभाषा
Close duration	Finance sign-off तक कार्यदिवस और शेष अंतर का कारण।
Count-line accuracy	सही SKU-location lines ÷ जाँची गई lines × 100।
Overselling	गलत sellable stock के कारण पूरे न हो सके स्वीकार किए गए orders।
Reconciliation effort	वही data लाने और जाँचने में लगे staff-hours।
Unmatched settlement	अनसुलझी रकम और उसकी उम्र; fees, refunds व partial payments सहित।

उदाहरण: 200 जाँची गई SKU-location count lines में 196 सही हों तो count-line accuracy 98% है। इसका मतलब stock value भी 98% सही हो, यह ज़रूरी नहीं। समान sampling, units और समयावधि में तुलना करें।

इसमें StoreConsole की भूमिका

StoreConsole demo में केवल feature list नहीं, अपना workflow जाँचें। Modules, permissions, integrations, hosting और recovery की ज़िम्मेदारियाँ स्पष्ट करके ही scope और launch date तय करें।

सार

• एक महँगी coordination problem और मापे हुए baseline से शुरू करें।
• Ownership, duplicate handling, reconciliation और recovery तय करें।
• Evidence न मिले तो समय बढ़ाएँ; मंज़ूर चरणों में आगे बढ़ें।
• Sensitive decisions और exceptional transactions लोगों के नियंत्रण में रखें।

स्रोत और समीक्षा

Microsoft की implementation guidance migration rehearsal और business sign-off पर ज़ोर देती है। यहाँ समयसीमा व गणनाएँ editorial planning examples हैं, Microsoft की अनिवार्य शर्तें नहीं। समीक्षा: 4 नवंबर 2026।

• Microsoft Learn: go-live checklist
• Microsoft Learn: cutover strategy

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।