Single-school vs multi-school ERP: आप असल में कौन-सा खरीद रहे हैं multi-school
भारत का लगभग हर school ERP कहता है कि वह कई schools चला सकता है। बहुत कम उस तरह बने हैं। यह guide बताती है कि दोनों के बीच असली फ़र्क़ किस एक बात से तय होता है, वह छह-सूत्री demo test क्या है जो दस मिनट में सच खोल देता है, और इसकी क़ीमत कितनी होनी चाहिए।
लखनऊ का एक trust तीन campus चलाता है। तीनों ने वही जाना-माना ERP खरीदा, तो office ने मान लिया कि वे "एक ही system पर" हैं। June में director ने एक ही number माँगा — आज तीनों campus मिलाकर कितने students on roll हैं — और जवाब में तीन spreadsheet आईं, जिनमें से दो अब भी पिछले साल के leavers गिन रही थीं। किसी ने लापरवाही नहीं की थी। software एक school के लिए बना था और तीन बार बेचा गया, तो उसके भीतर कहीं "trust" नाम की चीज़ थी ही नहीं। तीन campus, data के तीन अलग ढेर, सच के तीन version। और brochure पर multi-school शब्द शुरू से लिखा हुआ था।
यह वह फ़र्क़ है जो लगभग कोई brochure नहीं बताता। कुछ system एक school को software की एक copy मानते हैं। कुछ एक school को एक organisation के भीतर का पता मानते हैं। आप जिस भी चीज़ की परवाह करते हैं वह इसी एक चुनाव से तय होती है — group view तुरंत मिलेगा या Excel का काम बनेगा, कोई student campus बदल पाएगा या नहीं, एक login तीनों campus खोलेगा या आपको तीन login संभालने पड़ेंगे। यह feature list में नहीं दिखता। यह demo के दस मिनट में दिख जाता है, बशर्ते आपको पूछना आता हो।
"multi-school" के नाम पर बिकने वाली तीन architecture
जब कोई vendor कहता है कि वह कई schools support करता है, तो उसका मतलब इन तीन में से कोई एक होता है — और तीनों बहुत अलग हैं।
एक: अलग-अलग installation. हर campus को system की अपनी copy मिलती है, अपना login, अपना data। यह sales contract के हिसाब से multi-school है, software के हिसाब से नहीं। भारत में multi-branch के नाम पर सबसे ज़्यादा यही बिकता है, और तीन-spreadsheet वाली समस्या यहीं से आती है।
दो: एक system, flat data. सारे campus data का एक ही ढेर साझा करते हैं, जिसे एक filter अलग रखता है — वह filter हर screen और हर report पर किसी को याद रखकर लगाना पड़ता है। group total मुमकिन हैं। कभी-कभी campus के बीच leak भी मुमकिन हैं — कोई class list या Fees ledger वहाँ दिख जाना जहाँ नहीं दिखना चाहिए।
तीन: organisation-first. organisation ही system की जड़ है और हर school उसके भीतर बैठता है। campus system की हर चीज़ के पते का हिस्सा है, इसलिए वह कभी छूट नहीं सकता, और group view बनाने में कुछ खर्च नहीं होता क्योंकि data कभी बँटा ही नहीं था। तीनों में से सिर्फ़ यही एक है जहाँ chairman के सवाल का जवाब उसी सेकंड मिलता है।
एक असली multi-school platform को क्या करना ही होगा
फ़र्क़ यह नहीं है कि group को ज़्यादा features चाहिए। फ़र्क़ यह है कि group को एक ऐसी layer चाहिए जिसका single-school software को कोई पता ही नहीं होता। ये वे क्षमताएँ हैं जो तभी बनती हैं जब organisation जड़ हो।
Multi-school capability checklist
- हर campus पर एक organisation view — पूरे group के students on roll, staff, admissions, attendance और fee collection एक screen पर, campus-wise तुलना के साथ — चार login जिनके बीच आप tab करें, वह नहीं।
- एक login, कई campus — director या trust accountant एक बार sign in करे और system के भीतर से campus बदले, न कि diary में चार सेट credentials रखे।
- अलग academic calendar पर campus — एक असली group platform में Campus A अपना session March में बंद कर सकता है जबकि Campus B अभी बीच साल में है, और group फिर भी सही report करता है। ज़्यादातर multi-school दावे यहीं चुपचाप ढह जाते हैं।
- campus से campus student movement — junior campus से senior campus जाने वाला student अपनी admission history, Fees record और academic record साथ ले जाए, नए admission की तरह दोबारा टाइप न हो।
- आपके org chart से मेल खाता access — principal सिर्फ़ अपना campus देखे, trust head सब देखे, accountant पूरे group की Fees देखे और उसके अलावा कुछ नहीं। सब कुछ खुला हुआ एक flat user list नहीं।
- साझा मानक, स्थानीय आज़ादी — grading scale, exam type, report card design और document format group के लिए एक बार तय हों, जबकि हर campus अपना timetable, अपनी Fees की due date और रोज़ का काम खुद चलाए।
- group भर के staff record — एक ही employee record तब भी जब कोई teacher दो campus पर periods लेता हो, और payroll सही campus पर लगे।
- consolidated पैसा — पूरे group का total collection और total dues एक live number की तरह, साथ में campus-wise split, बिना किसी export के।
- एक contract, एक invoice, एक renewal date — per-student pricing जो group की कुल संख्या दर्शाए, न कि चार छोटे-school quote एक के ऊपर एक।
- एक audit trail — किसने क्या बदला, किस campus पर — group को दिखे, हर campus की अपनी copy में फँसा न रहे।
भारत की कसौटी: दावा कहाँ टूटता है
भारतीय group school में दो हालात ऐसे हैं जो ज़्यादातर multi-school दावों को तुरंत तोड़ देते हैं। पहला academic calendar। एक ही trust के campus सचमुच अलग session पर चलते हैं — कोई campus बीच साल में खुला, कोई senior wing board calendar पर है, कोई अभी-अभी लिया गया school अपना साल पूरा कर रहा है। जो software पूरे organisation के लिए एक ही calendar मान लेता है, वह हर बेमेल campus के लिए zero दिखाता है — जो कुछ न दिखाने से भी बुरा है।
दूसरा वह student जो आपके ही campus के बीच जाता है। ज़्यादातर system में इसे exit और नया admission मानकर निपटाया जाता है, क्योंकि software को पता ही नहीं कि दोनों campus एक ही trust के हैं। family को एक transfer certificate मिल जाता है जिसकी कभी ज़रूरत नहीं थी, Fees history दो टुकड़ों में टूट जाती है, और बच्चा आपकी headcount में दो बार आ जाता है। भारत का हर group पहले ही साल में इन दोनों से टकराता है। और लगभग कोई demo इनमें से किसी को नहीं छूता।
कैसे चुनें: छह-सूत्री demo test
feature list स्वीकार मत कीजिए। vendor से organisation layer live साबित करवाइए, ऐसे data पर जिसमें एक से ज़्यादा campus हों।
- हर campus एक screen पर माँगें। students on roll, आज की attendance और fee collection, campus दर campus। अगर जवाब है "हर campus में अलग login करते हैं", तो आपके सामने single-school software है, multi-branch की क़ीमत पर।
- दो campus को अलग academic session पर रखवाएँ। Campus A को बंद session पर और Campus B को चालू session पर सेट करवाकर group view दोबारा खोलें। अगर number zero हो जाएँ या screen error दे, तो group layer एक ही calendar मानकर बना है और आपके दूसरे campus पर ही दम तोड़ देगा।
- एक student को एक campus से दूसरे पर ले जाएँ। ध्यान से देखिए कि admission history, Fees ledger और marks बच्चे के साथ जाते हैं या उसे नए की तरह admit किया जाता है। पूरी evaluation में यही सबसे तेज़ test है और इसमें नब्बे सेकंड लगते हैं।
- आपके सामने दो लोग बनवाएँ। एक principal जो सिर्फ़ अपना campus देख सके, और एक trust head जो सब देख सके। फिर उसी principal से दूसरा campus खुलवाने की कोशिश करवाएँ। अगर वह खुल गया, तो access सिर्फ़ सजावट है।
- एक बार login करके campus बदलें। पुष्टि करें कि एक व्यक्ति logout किए बिना campus के बीच जा सकता है। चार सेट credentials इस बात की निशानी है कि ये एक नाम पहने चार system हैं।
- एक contract और एक invoice माँगें। पुष्टि करें कि group की pricing group की तरह है, organisation view premium tier में नहीं बल्कि शामिल है, और साफ़ पूछें कि online payment gateway charge कौन भरता है।
जो नाम आपको मिलेंगे
भारतीय market में असली multi-campus platform भी हैं और branch selector लगे single-school product भी, और दोनों के brochure एक जैसे पढ़े जाते हैं। जो नाम आपको मिलेंगे उनमें Entab (CampusCare), जो बड़ी CBSE chain में लंबे समय से जमा है; Next Education, जिसका NextERP बड़े पैमाने पर और साफ़-साफ़ single-login, all-branches वाली pitch के साथ बेचा जाता है; Edunext; Fedena, जो सालों से multi-institute setup support करता है; MyClassboard; Campus 365; edumerge, जो ख़ास तौर पर दो से पचास-से-ज़्यादा campus वाले group को target करता है; और Inkwelly जैसे नए organisation-first platform शामिल हैं। इनमें से कुछ छहों test पास कर देंगे। कई पहला पास करके तीसरे पर गिर जाएंगे। बात vendor की उम्र या size की नहीं है — बात यह है कि organisation software के भीतर एक असली चीज़ की तरह मौजूद है या नहीं, और यह पता करने का अकेला तरीक़ा है कि आप उन्हें दिखाने पर मजबूर करें।
pricing की हक़ीक़त
भारतीय school software लगभग ₹20–₹100 प्रति student सालाना चलता है, और multi-school खरीदार के पास जितनी मोलभाव की ताक़त होती है वे आम तौर पर उससे कम इस्तेमाल करते हैं। group volume पर — मान लीजिए तीन campus में 3,000 students — आपको ₹20–₹40 band में एक ही बातचीत किया हुआ rate लेना चाहिए, न कि तीन अलग छोटे-school quote जो चुपचाप जुड़कर दोगुने हो जाते हैं। दो बातें लिखवा लेना ज़रूरी है। पहली, कि organisation view और campus-to-campus transfer product का हिस्सा हैं, कोई enterprise upgrade नहीं; group layer के लिए अलग पैसे लेना उसी चीज़ के अलग पैसे लेना है जिसके लिए आप आए थे। दूसरी, online Fees पर gateway charge, जो आम तौर पर हर transaction पर 1.5–2% होता है और जिसे ज़्यादातर भारतीय स्कूल parents पर डालते हैं — पुष्टि करें कि यह हर campus पर एक जैसा है, क्योंकि campus दर campus अलग gateway setting एक आम और आसानी से टलने वाली गड़बड़ है। और एक ही renewal date पर ज़ोर दें। चार महीनों में चार renewal आपके office के समय में एक असली खर्च है।
Inkwelly कहाँ बैठता है
Inkwelly बनावट से ही organisation-first है: organisation जड़ है और हर school उसके भीतर रहता है, इसलिए campus system के हर student, invoice, mark और message के पते का हिस्सा है। यही वजह है कि group view जोड़-तोड़ करके नहीं बनता, तुरंत मिलता है — और यही वजह है कि अलग academic session पर चल रहे campus भी सही report करते हैं, जो मामला ज़्यादातर group software ग़लत करता है। आपके अपने campus के बीच किसी student को ले जाना एक first-class action है जो उसका record साथ ले जाता है, exit और दोबारा admission नहीं। access आपके org chart से मेल खाता है role-based permissions के ज़रिए, एक login हर उस campus को खोलता है जिसका किसी को हक़ है, और पूरा group एक contract पर चलता है पारदर्शी per-student pricing के साथ। अगर आप group चलाते हैं, हमारी बात पर मत जाइए — हम पर छह-सूत्री test चलाइए, और shortlist बनाने से पहले group और multi-branch buyer guide पढ़िए।
“सवाल यह नहीं है कि brochure पर multi-school लिखा है या नहीं। सवाल यह है कि organisation software के भीतर एक असली चीज़ की तरह मौजूद है या नहीं — और जो student आपके ही campus के बीच नहीं जा सकता, वही इसका जवाब है।”
दो हफ़्ते में तय करें
तीन platform shortlist करें और हर एक को multi-campus data पर वही छह-सूत्री test से गुज़ारें — एक जमा-जमाया enterprise नाम, एक mid-market product, और एक organisation-first platform। सिर्फ़ group layer पर score दीजिए; feature count छोड़ दीजिए, क्योंकि features पर लगभग सब एक जैसे क़रीब हैं। दो सवाल अपने आप पूरा मैदान अलग कर देंगे: क्या दो campus अलग academic session पर चल सकते हैं, और क्या कोई student अपनी history के साथ campus बदल सकता है। हमारे अनुभव में ये दो सवाल एक ही दोपहर में ज़्यादातर shortlist ख़त्म कर देते हैं। जो दोनों में बच जाए वह सचमुच multi-school है, और उसके बाद आप उन चीज़ों की तुलना पर लौट सकते हैं जिनकी तुलना आसान है।
अपना पूरा organisation एक screen पर देखें
20 मिनट का demo book करें और हम छह-सूत्री test live चलाकर दिखाएंगे — हर campus एक view में, दो campus अलग session पर, और एक student अपने record के साथ उनके बीच जाता हुआ।
अक्सर पूछे गए सवाल
8 सवालक्या Inkwelly single-school software है या यह कई schools support करता है?
Inkwelly organisation-first है, यानी कई schools इसकी नींव है, बाद में जोड़ी गई चीज़ नहीं। organisation system की जड़ है और हर school उसके भीतर बैठता है, इसलिए group अपने सारे campus एक view में देखता है, एक login कई campus खोल सकता है, campus अलग academic session पर चल सकते हैं, और कोई student अपनी Fees और academic history लेकर campus बदल सकता है। एक अकेला independent school भी ठीक इसी platform पर चलता है — बस उसके organisation के भीतर एक school होता है।
Single-school और multi-school ERP में फ़र्क़ क्या है?
Single-school software हर school को system की अलग copy मानता है, इसलिए group के पास कई login और data के कई ढेर आ जाते हैं जिन्हें Excel में जोड़ना पड़ता है। Multi-school software एक school को एक organisation के भीतर का पता मानता है, इसलिए group view पहले से मौजूद है और कुछ जोड़ना नहीं पड़ता। यह फ़र्क़ architecture का है, कोई feature नहीं जो बाद में जोड़ा जा सके।
ERP sach mein multi-school hai ya nahi, ye kaise pata karein?
demo में छह जाँच चलाइए: हर campus एक screen पर, दो campus अलग academic session पर, एक student history समेत campus बदलता हुआ, एक principal सिर्फ़ अपने campus तक सीमित, एक login जो campus बदले, और एक contract एक invoice के साथ। तीसरा test सबसे तेज़ है — अगर student नए campus पर एक ख़ाली नए admission की तरह पहुँचता है, तो यह single-school software है जो दो बार बेचा गया है।
क्या एक ही system में दो campus अलग academic session पर चल सकते हैं?
एक असली multi-school platform में हाँ — और आपको इस पर अड़ जाना चाहिए। भारतीय group में campus आम तौर पर बेमेल रहते हैं: कोई नया खुला campus, कोई senior wing board calendar पर, कोई अभी लिया गया school अपना साल पूरा करता हुआ। जो software पूरे group के लिए एक ही calendar मान लेता है वह हर बेमेल campus के लिए zero दिखाएगा। sign करने से पहले इसे live देखने को कहिए।
क्या कोई student बिना दोबारा admission लिए एक campus से दूसरे campus जा सकता है?
असली multi-school software में हाँ — एक ही trust के campus के बीच जाना एक first-class action है जो student की admission history, Fees ledger और academic record साथ ले जाता है। single-school product में इसे exit और नए admission की तरह निपटाया जाता है, जिससे Fees history दो टुकड़ों में टूटती है, family को बेवजह एक transfer certificate मिलता है, और वही बच्चा आपकी headcount में दो बार गिना जा सकता है।
क्या हर campus को अपना अलग login चाहिए?
नहीं चाहिए। एक व्यक्ति एक बार sign in करे और उन campus के बीच बदले जिनका उसे हक़ है। अगर vendor आपको हर campus के लिए अलग credentials थमाता है, तो यह सबसे साफ़ निशानी है कि ये एक brand नाम साझा करते अलग-अलग system हैं, न कि एक organisation-level platform।
Multi-school software single-school se mehnga hota hai kya?
प्रति student यह सस्ता होना चाहिए, महँगा नहीं। भारतीय school software लगभग ₹20–₹100 प्रति student सालाना चलता है, और group volume पर — campus भर में कुछ हज़ार students — आपको एक contract पर ₹20–₹40 band में एक rate पर मोलभाव करना चाहिए। इस पर सख़्त रहिए कि organisation view और campus-to-campus transfer product में शामिल हैं, किसी premium enterprise tier में नहीं।
क्या एक अकेला independent school multi-school software इस्तेमाल कर सकता है?
हाँ, और इसका कोई नुक़सान नहीं। एक अच्छी तरह बना organisation-first platform तब बिलकुल single-school software की तरह बर्ताव करता है जब organisation में एक ही school हो — group screen पर बस एक campus दिखता है। फ़ायदा यह है कि तीन साल बाद अगर आप दूसरा campus खोलते हैं, तो आप उसे जोड़ देते हैं, किसी दूसरे product पर migrate करके पूरी history दोबारा नहीं भरते।
आपको ये भी पसंद आ सकता है
5 लेखInkwelly आपके स्कूल पर — खुद देखें
30 मिनट का डेमो। आपके मौजूदा ERP को आपके साथ खोलकर, कॉल पर ही आपका डेटा Inkwelly में लोड करते हैं। कॉल ख़त्म होते-होते एक तय तारीख़ का गो-लाइव प्लान आपके हाथ में।