स्प्रेडशीट से एक भरोसेमंद सिस्टम तक: 90 दिनों में ERP लागू करने का व्यावहारिक रोडमैप

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

तीन साल बाद वही कंपनी हर महीने का पहला हफ़्ता इन टूल्स के आँकड़े आपस में मिलाने में लगा देती है। डैशबोर्ड पर किसी को पूरा भरोसा नहीं रहता, क्योंकि हर आँकड़ा कम से कम दो जगह अलग-अलग दर्ज होता है। यही वह मोड़ है जहाँ ERP "बड़ी कंपनियों की चीज़" नहीं रह जाता और एक सीधा, व्यावहारिक सवाल बन जाता है: कारोबार रोके बिना सारा डेटा एक भरोसेमंद जगह पर कैसे लाया जाए?

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

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

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

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

एक आसान टेस्ट कीजिए: आपकी टीम हर महीने एक सिस्टम से दूसरे सिस्टम में डेटा डालने या जाँचने में कितने घंटे लगाती है? 10 से 50 लोगों वाली जिन कंपनियों के साथ मैंने काम किया है, वहाँ ईमानदार जवाब आमतौर पर महीने में 40 से 120 घंटे होता है। यानी सिर्फ़ सॉफ़्टवेयर को आपस में तालमेल में रखने पर एक पार्ट-टाइम कर्मचारी की सैलरी ख़र्च हो रही है।

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

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

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

अगर इनमें से तीन या ज़्यादा बातें आप पर लागू होती हैं, तो सवाल यह नहीं रह जाता कि सब कुछ एक जगह लाएँ या नहीं; सवाल यह है कि सुरक्षित तरीक़े से कैसे लाएँ।

"इंटीग्रेटेड" का असली मतलब

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

यह event-driven आर्किटेक्चर से मुमकिन होता है। हर मॉड्यूल अपने डेटा का मालिक होता है — ऑर्डर, स्टॉक, खाता-बही, कर्मचारी। कुछ अहम होने पर मॉड्यूल एक event घोषित करता है: ऑर्डर आया, पेमेंट मिल गया, स्टॉक हिला, जर्नल पोस्ट हुआ। बाक़ी मॉड्यूल यह घोषणा सुनकर अपना काम कर लेते हैं। StoreConsole इसी तरह बना है: मॉड्यूल सिर्फ़ event और listener के ज़रिए बात करते हैं, कोई किसी की टेबल में सीधे हाथ नहीं डालता। इससे तीन बड़े फ़ायदे मिलते हैं:

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

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

एक बिक्री को इंटीग्रेटेड सिस्टम में शुरू से आख़िर तक देखिए, फ़र्क़ साफ़ दिख जाएगा:

कदम	क्या होता है	ज़िम्मेदार मॉड्यूल
1. ऑर्डर	वेबसाइट, POS, फ़ोन या चैट — कहीं से भी आए, वही क़ीमत, वही टैक्स, वही चेकआउट नियम।	Checkout
2. स्टॉक रिज़र्व	जिस लोकेशन से माल जाएगा, वहाँ मात्रा रोक दी जाती है; कोई दूसरा चैनल उसे नहीं बेच सकता।	Inventory
3. पेमेंट	कार्ड, COD, बैंक ट्रांसफ़र या पहले से तय पेमेंट टर्म्स।	Payment
4. जर्नल एंट्री	रेवेन्यू, टैक्स और बकाया रक़म अपने-आप खाते में पहुँच जाती है।	Accounting
5. कूरियर बुकिंग	डिलीवरी इंजन चार्ज तय करके कूरियर पर पार्सल बुक कर देता है।	Delivery
6. स्टेटस अपडेट	कूरियर के अपडेट से ऑर्डर डिलीवर्ड, आंशिक डिलीवर्ड या रिटर्न हो जाता है।	Order
7. कैश मिलान	कूरियर का वसूला COD ऑर्डर से मिलाकर खाते में दर्ज होता है।	Accounting
8. ग्राहक से जुड़ाव	लॉयल्टी पॉइंट जुड़ते हैं, CRM टाइमलाइन अपडेट होती है, रिव्यू का अनुरोध जाता है।	CRM, Loyalty

आठ कदम, और इंसान का अकेला काम है पार्सल पैक करना। "हमारे पास हर काम का सॉफ़्टवेयर है" और "हमारे सॉफ़्टवेयर मिलकर काम करते हैं" — इन दोनों में फ़र्क़ यहीं है।

90 दिनों में चरणबद्ध ERP रोडमैप

ERP प्रोजेक्ट के फ़ेल होने की सबसे बड़ी वजह है सब कुछ एक साथ लॉन्च करना: एक वीकेंड में सब चालू, सोमवार को पुराने सिस्टम बंद। फिर जब कोई गड़बड़ होती है — और होती ही है — तो कोई नहीं जानता कि दिक़्क़त किस हिस्से में है।

इसकी जगह चरणों में आगे बढ़िए: हर चरण चालू हो, कुछ दिन स्थिर चले, फिर अगला शुरू हो। एक से पाँच लोकेशन वाले बिज़नेस के लिए मेरी सलाह है यह 13 हफ़्तों की योजना।

चरण 0 — डेटा ऑडिट (हफ़्ते 1–2)

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

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

चरण 1 — कैटलॉग और स्टॉक (हफ़्ते 3–5)

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

नतीजा: स्टॉक का एक ही आँकड़ा, जिसे हर चैनल पढ़ता है।

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

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

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

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

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

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

चरण 4 — रिपोर्ट और ऑटोमेशन (हफ़्ते 12–13)

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

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

सीधा-सा नियम: जब तक पिछला चरण कम से कम एक पूरा हफ़्ता बिना किसी मैन्युअल सुधार के न चले, अगला चरण शुरू मत कीजिए। एक हफ़्ते का धैर्य एक महीने की भागदौड़ से कहीं सस्ता है।

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

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

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

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

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

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

पहले हफ़्ते में टीम जो बदलाव माँगती है, छठे हफ़्ते तक अक्सर उनकी ज़रूरत ही नहीं रहती। पहले एक महीना स्टैंडर्ड प्रोसेस पर चलाइए। इंटीग्रेटेड फ़्लो देखने के बाद ज़्यादातर "इसके बिना काम नहीं चलेगा" वाली माँगें अपने-आप ख़त्म हो जाती हैं।

3. मॉड्यूल का कोई ज़िम्मेदार नहीं

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

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

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

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

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

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

शुरू करने से पहले इन आँकड़ों पर सहमति बनाइए, चरण 0 में एक बार नापिए, और लॉन्च के 90 दिन बाद दोबारा नापिए:

KPI	आमतौर पर पहले	अच्छी स्थिति में बाद में
महीना क्लोज़ करने में कितने दिन	7–12	2–3
स्टॉक की सटीकता (सिस्टम बनाम गिनती)	85–92%	98% से ज़्यादा
महीने में स्टॉक से ज़्यादा बिके ऑर्डर	कई	लगभग शून्य
डेटा इधर-उधर करने में लगे घंटे	40–120	10 से कम
बिना मिलान वाले COD सेटलमेंट	किसी को पता नहीं	रोज़ सूची, हर हफ़्ते निपटारा
"प्रोडक्ट के हिसाब से मुनाफ़ा?" — जवाब मिलने का समय	कई दिन	कुछ सेकंड

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

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

StoreConsole ठीक इसी रोडमैप को ध्यान में रखकर बनाया गया है। कॉमर्स, इन्वेंटरी, POS, डिलीवरी, अकाउंटिंग, HR, पेरोल, CRM — हर एक अलग मॉड्यूल है, लेकिन सब एक ही डेटाबेस इस्तेमाल करते हैं और event के ज़रिए एक-दूसरे को ख़बर देते हैं। आज जितना चाहिए उतना चालू कीजिए, तैयार होने पर बाक़ी जोड़िए, और सब कुछ अपने ही सर्वर पर चलाइए ताकि डेटा आपके हाथ में रहे। पूरी प्रक्रिया देखनी हो तो लाइव डेमो खुला है, और सभी मॉड्यूल की सूची ERP पेज पर है।

सार

• अलग-अलग टूल्स की असली लागत उनके बीच तालमेल के काम में है — आमतौर पर महीने में 40–120 घंटे।
• "इंटीग्रेटेड" का मतलब है एक घटना और उस पर कई अपने-आप होने वाली प्रतिक्रियाएँ — सिर्फ़ एक जैसा लॉगिन पेज नहीं।
• चरणों में लागू कीजिए: डेटा ऑडिट, कैटलॉग और स्टॉक, ऑर्डर और पैसा, लोग और पेरोल, फिर रिपोर्ट और ऑटोमेशन।
• पैसे से जुड़े हर चरण में कम से कम एक महीने पुराना और नया सिस्टम साथ-साथ चलाइए।
• शुरुआत से पहले KPI तय कीजिए, ताकि बाद में साबित कर सकें कि बदलाव सच में काम आया।

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