अपना सॉफ़्टवेयर ख़रीदें या बनाएं का शाश्वत प्रश्न (जेम्स मोनाघन) प्लेटोब्लॉकचेन डेटा इंटेलिजेंस। लंबवत खोज. ऐ.

आपका सॉफ्टवेयर खरीदना है या बनाना है इसका शाश्वत प्रश्न (जेम्स मोनाघन)

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

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

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

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

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

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

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

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

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

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

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

समय टिकट:

से अधिक फिनटेक्स्ट्रा