AI कंसल्टेंट्स एक इन-हाउस SaaS रिप्लेसमेंट का स्कोप कैसे तय करते हैं

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

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

SaaS रिप्लेसमेंट स्कोप में वास्तव में क्या शामिल होता है?

कार्यों की एक सूची (jobs inventory), फ़ीचर सूची नहीं। कंसल्टेंट टूल द्वारा किए जाने वाले हर काम, प्रत्येक काम को कौन संभालता है, और जब इसका आउटपुट गलत होता है तो क्या होता है, इसकी सूची बनाता है। मंज़ूरी की शृंखलाएं (approval chains), डैशबोर्ड और फॉर्म एक कॉलम में जाते हैं। पैसे का लेन-देन, स्टॉक की गिनती, टैक्स और कर्मचारियों के रिकॉर्ड दूसरे कॉलम में जाते हैं। अंतिम परिणाम वह मैप, प्रति कार्य जोखिम ग्रेड, और उन सभी सिस्टम्स की सूची है जिनसे टूल चुपचाप जुड़ा हुआ है।

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

प्रोडक्ट को दो लेयर्स में क्यों विभाजित करें?

क्योंकि AI ने एक लेयर की लागत को समाप्त कर दिया और दूसरी लेयर को वैसा ही छोड़ दिया। इंटरफेस लेयर (फॉर्म, डैशबोर्ड, इंटरनल टूल्स, अप्रूवल वर्कफ़्लो) को अब फिर से बनाना तेज़ है; वर्तमान मॉडल घंटों में काम करने वाले वेब ऐप्स जेनरेट करते हैं, जो ठीक वही है जो हमने तब पाया जब हमने पूछा क्या GPT-5.6 एक काम करने वाला POS बना सकता है। इंफ्रास्ट्रक्चर लेयर अलग है: पेमेंट प्रोसेसिंग, PCI कंप्लायंस (कार्ड-सुरक्षा नियम जिन्हें प्रोसेसर लागू करते हैं), समवर्ती स्थितियों (concurrency) के तहत इन्वेंट्री (दो कैश काउंटर एक ही अंतिम यूनिट बेच रहे हैं), और रिपोर्ट जो मिलान करती हैं (कुल योग जो आपके बैंक डिपॉजिट से मेल खाते हैं)। वह लेयर इसलिए कठिन नहीं है क्योंकि कोड लंबा है। यह कठिन है क्योंकि वहाँ लगभग सही होने का कोई मूल्य नहीं है, और सटीकता साबित करने में कोड जेनरेट करने से ज़्यादा लागत आती है।

बेहतर मॉडल भी उस बाधा को दूर नहीं करते हैं। बाधा सत्यापन (verification) और उत्तरदायित्व है, कोड जेनरेशन नहीं, इसलिए एक ईमानदार स्कोप सत्यापन की कीमत तय करता है। जेनरेशन तो केवल डेमो है। सत्यापन ही वास्तविक चालान (invoice) है।

क्लार्ना के SaaS रिप्लेसमेंट ने वास्तव में क्या साबित किया?

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

वह हिम्मत की कमी नहीं थी। वह स्कोप का सही ढंग से काम करना था।

कौन से आंकड़े रिप्लेसमेंट प्रोजेक्ट को सही ठहराते हैं?

पहले बर्बादी रोकें, फिर निर्माण करें। ज़ायलो का 2026 SaaS मैनेजमेंट इंडेक्स, जो प्रबंधन के तहत 40 मिलियन से अधिक लाइसेंसों से लिया गया है, प्रति वर्ष प्रति कर्मचारी मध्यस्थ SaaS खर्च $9,455 बताता है, यह पाता है कि औसतन 36% लाइसेंस अप्रयुक्त पड़े हैं, और दिखाता है कि बिजनेस यूनिट्स SaaS खर्च के 81% को नियंत्रित करती हैं जबकि IT सीधे 15% का प्रबंधन करता है²। एक कंसल्टेंट कुछ भी प्रस्तावित करने से पहले आपके स्टैक को उन आंकड़ों के खिलाफ रैंक करता है: अप्रयुक्त सीटों को रद्द करें, ओवरलैपिंग टूल्स को समेकित करें, और केवल तभी रीबिल्ड के उम्मीदवारों को शॉर्टलिस्ट करें।

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

इस स्कोपिंग में POS कहाँ आता है?

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

इसलिए कंसल्टेंट्स POS रीबिल्ड का स्कोप उसी तरह तय करते हैं जैसे क्लार्ना ने अपने लेजर का तय किया था: कस्टम इंटरफेस, प्रमाणित इंफ्रास्ट्रक्चर। उस विभाजन के लिए पहले एक डेवलपर टीम की आवश्यकता होती थी। अब यह एक उत्पाद श्रेणी है: Final का Build एक साधारण-भाषा प्रॉम्प्ट को एक चेकआउट फ्लो में बदल देता है जिसे आप प्रिव्यू और डिप्लॉय कर सकते हैं, और आप उसी कॉमर्स इंफ्रास्ट्रक्चर के खिलाफ निर्माण करने के लिए MCP के माध्यम से अपने खुद के AI को कनेक्ट कर सकते हैं। भुगतान, इन्वेंट्री, रिपोर्टिंग और हार्डवेयर उस लेयर पर बने रहते हैं जो पहले से सत्यापित है।

तो आपको इन-हाउस SaaS रिप्लेसमेंट का स्कोप कैसे तय करना चाहिए?

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

और यदि आपके स्टैक का कॉमर्स हिस्सा वह भाग है जिसे आप फिर से बनाना चाहते हैं, तो एक ईमानदार नज़र से शुरुआत करें कि आज के मॉडल अपने आप क्या बना सकते हैं और क्या नहीं: एक वास्तविक POS निर्माण पर Claude बनाम ChatGPT बनाम Gemini, या कस्टम POS बनाने के लिए Gemini 3.6 Flash का उपयोग कैसे करें में दो नो-कोड रास्ते।