कस्टम सॉफ़्टवेयर या रेडीमेड समाधान (SaaS)?

बुडापेस्ट की सॉफ़्टवेयर विकास कंपनी Mesterséges Intelligencia Központ Kft. के अनुसार, रेडीमेड सॉफ़्टवेयर (SaaS) तब काफ़ी है जब वह प्रक्रियाओं को पूरा करता हो; कस्टम सॉफ़्टवेयर तब फ़ायदेमंद है जब कामकाज सामान्य से अलग हो, या सॉफ़्टवेयर ख़ुद ही व्यावसायिक बढ़त हो।

मुख्य बात: अगर कोई रेडीमेड उत्पाद बिना विकास के प्रक्रियाओं के बड़े हिस्से को पूरा करता है, और कंपनी उसके अनुसार ढलने को तैयार है, तो रेडीमेड समाधान तेज़ रास्ता है। अगर कामकाज उससे अलग है जिस पर रेडीमेड उत्पाद आधारित होते हैं, कई सिस्टमों को जोड़ना है, या डेटा और आगे के विकास पर नियंत्रण एक रणनीतिक सवाल है, तो कस्टम विकास फ़ायदेमंद है। अक्सर दोनों मिलकर सही जवाब होते हैं: रेडीमेड आधार, कस्टम पूरक के साथ।

कस्टम सॉफ़्टवेयर, रेडीमेड सॉफ़्टवेयर और SaaS का क्या अर्थ है?

ये तीनों अवधारणाएँ दो अलग-अलग सवालों का जवाब देती हैं: एक यह कि सॉफ़्टवेयर किसके लिए बना है, और दूसरा यह कि वह उपयोगकर्ता तक कैसे पहुँचता है।

कस्टम सॉफ़्टवेयर: किसी एक कंपनी की ज़रूरतों के लिए, ऑर्डर पर विकसित किया गया प्रोग्राम। वह वही करता है जो ग्राहक ने विनिर्देश में माँगा था, उसी तरह जैसे वहाँ लोग काम करते हैं, और आगे के विकास की दिशा भी ग्राहक ही तय करता है।
रेडीमेड (पैकेज्ड) सॉफ़्टवेयर: कई ग्राहकों के लिए बनने वाला उत्पाद, जिसका लाइसेंस कंपनी लेती है, और जिसे वह आमतौर पर अपने कंप्यूटरों या सर्वर पर इंस्टॉल करके चलाती है। सेटिंग्स से इसे ढाला जा सकता है, लेकिन इसके कामकाज का तर्क निर्माता तय करता है।
SaaS (Software as a Service, सेवा के रूप में सॉफ़्टवेयर): रेडीमेड सॉफ़्टवेयर, जिसे निर्माता अपने क्लाउड में चलाता है, और कंपनी सब्सक्रिप्शन लेकर ब्राउज़र से या प्रोग्रामिंग इंटरफ़ेस के ज़रिए उसका उपयोग करती है। प्रोग्रामिंग इंटरफ़ेस (API, application programming interface) वह जुड़ाव बिंदु है, जिसके ज़रिए दो प्रोग्राम बिना मानवीय हस्तक्षेप के डेटा का आदान-प्रदान करते हैं।

अमेरिका के राष्ट्रीय मानक और प्रौद्योगिकी संस्थान (NIST) की क्लाउड परिभाषा के अनुसार, SaaS में उपयोगकर्ता सेवा प्रदाता के क्लाउड में चल रहे ऐप्लिकेशन का उपयोग करता है, और उसके पीछे के बुनियादी ढाँचे (नेटवर्क, सर्वर, ऑपरेटिंग सिस्टम, स्टोरेज) का प्रबंधन नहीं करता, यहाँ तक कि ऐप्लिकेशन की अलग-अलग क्षमताओं का भी नहीं, सिवाय सीमित, उपयोगकर्ता-स्तर की सेटिंग्स के (NIST SP 800-145)। यही SaaS की ताक़त भी है और सीमा भी: निर्माता संचालन का बोझ कंपनी के कंधों से उतार लेता है, लेकिन यह भी वही तय करता है कि उत्पाद में क्या और कब बदलेगा।

तीसरा रास्ता: रेडीमेड आधार, कस्टम पूरक के साथ

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

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

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

एक तालिका में निर्णय के मानदंड

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

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

स्वामित्व की कुल लागत किस पर निर्भर करती है?

स्वामित्व की कुल लागत (अंग्रेज़ी में total cost of ownership, संक्षेप में TCO) सॉफ़्टवेयर के पूरे उपयोग-काल पर होने वाला ख़र्च है, न कि सिर्फ़ शुरुआत की क़ीमत। दोनों रास्तों की लागत संरचना अलग है, इसलिए सिर्फ़ एक साल की तुलना भ्रामक हो सकती है: योजनाबद्ध उपयोग-काल को देखना उचित है।

रेडीमेड सॉफ़्टवेयर और SaaS में लागत आमतौर पर इनसे तय होती है:

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

कस्टम सॉफ़्टवेयर में:

विकास, जो मुख्य रूप से सॉफ़्टवेयर के कार्यात्मक आकार पर निर्भर करता है;
संचालन: होस्टिंग, निगरानी और सुरक्षा अपडेट;
रखरखाव और आगे का विकास, जैसे-जैसे कंपनी की ज़रूरतें बदलती हैं;
ज्ञान को बनाए रखना: दस्तावेज़ीकरण और पूरा सोर्स कोड, ताकि सिस्टम किसी एक व्यक्ति पर निर्भर न रहे।

कस्टम विकास की लागत की योजना तब बनाई जा सकती है, जब दायरे को अंदाज़े से आँकने के बजाय मापा जाए। हम विकास के कार्यात्मक आकार को COSMIC फ़ंक्शन पॉइंट (ISO/IEC 19761) में मापते हैं, और इसी से प्रस्ताव और समय-सारिणी बनती है; यह पद्धति मूल्य निर्धारण पृष्ठ पर बताई गई है। लंबी अवधि में कौन-सा रास्ता कम ख़र्चीला है, यह उपयोगकर्ताओं की संख्या, बदलावों की आवृत्ति और एकीकरणों की मात्रा पर निर्भर करता है। इसका कोई सामान्य जवाब नहीं है, सिर्फ़ ठोस मामले के लिए की गई गणना।

निर्माता पर निर्भरता और डेटा पोर्टेबिलिटी

निर्माता पर निर्भरता (अंग्रेज़ी में vendor lock-in) की बात तब होती है, जब किसी दूसरे उत्पाद पर जाना इतना कठिन या महँगा हो कि कंपनी व्यावहारिक रूप से बाहर नहीं निकल सकती। इसका कारण बंद डेटा फ़ॉर्मेट, अधूरा एक्सपोर्ट, सिर्फ़ उसी उत्पाद से बँधी ढेर सारी सेटिंग्स, या ऐसा अनुबंध हो सकता है जिसे समाप्त करना कठिन हो।

यूरोपीय संघ का डेटा अधिनियम (Data Act, विनियमन (EU) 2023/2854) 12 सितंबर 2025 से लागू है, और एक अलग अध्याय में डेटा प्रसंस्करण सेवाओं के बीच बदलाव को नियंत्रित करता है; इसकी प्रस्तावना SaaS को भी इन्हीं सेवाओं में गिनती है। विनियमन का पाठ अन्य बातों के साथ यह अनिवार्य करता है (17 अक्टूबर 2026 को जाँचा गया):

बदलाव की शर्तें लिखित अनुबंध में दर्ज होनी चाहिए, और बदलाव शुरू करने के लिए नोटिस अवधि अधिकतम दो महीने हो सकती है (अनुच्छेद 25)।
अनुरोध पर, बदलाव को बिना अनुचित देरी के, अधिकतम 30 कैलेंडर दिनों की संक्रमण अवधि के भीतर संभव बनाया जाना चाहिए, और इस दौरान सेवा चलती रहनी चाहिए; अगर यह तकनीकी रूप से संभव न हो, तो सेवा प्रदाता कारण बताते हुए अधिकतम सात महीने की संक्रमण अवधि तय कर सकता है (अनुच्छेद 25)।
अनुबंध में स्थानांतरित किए जा सकने वाले डेटा की मद-दर-मद सूची होनी चाहिए, और डेटा वापस पाने के लिए कम से कम 30 कैलेंडर दिनों की अवधि देनी चाहिए (अनुच्छेद 25)।
12 जनवरी 2027 से सेवा प्रदाता बदलाव की प्रक्रिया के लिए कोई शुल्क नहीं ले सकता; तब तक सिर्फ़ घटा हुआ शुल्क ले सकता है, जो बदलाव से सीधे जुड़ी उसकी लागतों से ज़्यादा नहीं हो सकता (अनुच्छेद 29)।

एक महत्वपूर्ण अपवाद यह है कि शुल्क से जुड़ा नियम और कुछ तकनीकी दायित्व उन सेवाओं पर लागू नहीं होते, जिनकी मुख्य विशेषताएँ बड़े पैमाने पर किसी एक ग्राहक की ज़रूरतों के अनुसार बनाई गई हैं, और जो व्यापक रूप से पेश नहीं की जातीं (अनुच्छेद 31)। अगर रेडीमेड सिस्टम कंपनी की ओर से व्यक्तिगत डेटा संसाधित करता है, तो सामान्य डेटा संरक्षण विनियमन (GDPR) भी सेवा प्रदाता पर दायित्व डालता है: सेवा के अंत में वह डेटा नियंत्रक के निर्णय के अनुसार सारा व्यक्तिगत डेटा मिटा देता है या लौटा देता है (GDPR, अनुच्छेद 28(3)(g))। यह जानकारी है, क़ानूनी सलाह नहीं।

क़ानून शर्तों को बेहतर बनाता है, लेकिन बाहर निकलने की योजना कंपनी को ही बनानी होती है, और हो सके तो चुनाव के समय ही। यह देखना उचित है:

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

सोर्स कोड किसका है?

रेडीमेड सॉफ़्टवेयर और SaaS में कंपनी उपयोग का अधिकार ख़रीदती है: सोर्स कोड निर्माता के पास रहता है, और उत्पाद के भविष्य (नई सुविधाओं, क़ीमत में बदलाव, उत्पाद के बंद होने) का फ़ैसला निर्माता करता है। अगर उत्पाद स्थिर है और डेटा बाहर निकाला जा सकता है, तो यह अपने आप में कोई समस्या नहीं है।

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

हर सिस्टम प्रकार में आकलन अलग होता है

ऊपर दिए मानदंड सामान्य हैं, लेकिन हर सिस्टम प्रकार में उनका वज़न अलग होता है। उद्यम संसाधन योजना सिस्टम में निर्णायक सवाल अनुकूलन और अपग्रेड की संभावना के बीच का संतुलन है। इसके बारे में हम कस्टम ERP या अनुकूलित रेडीमेड ERP? लेख में लिखते हैं। ग्राहक प्रबंधन सिस्टम में विशेष बिक्री प्रक्रिया और प्रति उपयोगकर्ता लाइसेंस बहुत मायने रखते हैं (देखें कस्टम CRM विकसित करना कब फ़ायदेमंद है? लेख)। वेबशॉप में किराए के प्लेटफ़ॉर्म की तेज़ शुरुआत का मुक़ाबला मुक्त विस्तार की संभावना से है; देखें वेबशॉप: किराए का सिस्टम या कस्टम विकास? लेख। व्यावसायिक सिस्टमों के विकास के बारे में आम तौर पर आप व्यावसायिक सॉफ़्टवेयर पृष्ठ पर पढ़ सकते हैं।

निर्णय के लिए जाँच-सूची

नीचे दिए सवालों के जवाब ज़्यादातर अपने आप रास्ता तय कर देते हैं:

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

आमतौर पर होने वाली ग़लतियाँ

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

अक्सर पूछे जाने वाले प्रश्न

कस्टम सॉफ़्टवेयर विकसित करना कब फ़ायदेमंद है?

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

क्या लंबी अवधि में कस्टम सॉफ़्टवेयर ज़्यादा महँगा होता है?

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

अगर हम SaaS रद्द कर दें, तो हमारे डेटा का क्या होगा?

यह मुख्य रूप से अनुबंध पर निर्भर करता है, इसलिए इसे चुनाव के समय ही देखना उचित है। यूरोपीय संघ के डेटा अधिनियम के अनुसार अनुबंध में स्थानांतरित किए जा सकने वाले डेटा को मद-दर-मद तय करना होता है, और उसे निकालने के लिए कम से कम 30 कैलेंडर दिन देने होते हैं; और GDPR के अनुसार सेवा के अंत में व्यक्तिगत डेटा को डेटा नियंत्रक के निर्णय के अनुसार मिटाना या लौटाना होता है। व्यवहार में, एक परीक्षण एक्सपोर्ट दिखाता है कि डेटा किसी दूसरे सिस्टम में कितना उपयोगी है।

क्या दोनों को मिलाया जा सकता है?

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

सोर्स कोड किसका होगा?

रेडीमेड सॉफ़्टवेयर और SaaS में सोर्स कोड निर्माता का होता है, और कंपनी को उपयोग का अधिकार मिलता है। कस्टम विकास में सोर्स कोड और उपयोग के अधिकार अनुबंध में तय होते हैं, हमारे यहाँ भी।

हम कैसे मदद करते हैं?

Mesterséges Intelligencia Központ Kft. कस्टम सॉफ़्टवेयर विकसित करती है और रेडीमेड सिस्टमों को आपस में जोड़ती है, और जहाँ इससे सचमुच काम बचता है, वहाँ कृत्रिम बुद्धिमत्ता के साथ भी: हम OpenAI (ChatGPT), Anthropic (Claude) और Google (Gemini) के भाषा मॉडलों को मौजूदा सिस्टमों से जोड़ते हैं। पहला परामर्श निःशुल्क है, और अगर कोई रेडीमेड उत्पाद काफ़ी हो, तो उसमें हम यह भी बता देते हैं। अगर कस्टम विकास चाहिए, तो हम उसके कार्यात्मक आकार को COSMIC फ़ंक्शन पॉइंट में मापते हैं, और इसी से प्रस्ताव और समय-सारिणी बनती है। अनुरोध पर हम गोपनीयता समझौता (NDA) करते हैं, और हस्तांतरण के बाद हम संचालन और रखरखाव की ज़िम्मेदारी भी लेते हैं। सोर्स कोड और उपयोग के अधिकार अनुबंध में तय होते हैं।

विवरण कस्टम सॉफ़्टवेयर विकास पृष्ठ पर है। अगर आप अपनी स्थिति के बारे में हमसे बात करना चाहें, तो संपर्क पृष्ठ पर दिए गए विवरणों पर हमें लिखें।