विक्रेता के बारे में क्या नहीं बताया जाएगा: ईसीएम प्रणाली चुनने की तकनीकी सूक्ष्मता

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

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


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

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

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

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

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

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

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

सबसे पहले, आपको निश्चित रूप से वास्तुकला की सुविधाओं पर ध्यान देना चाहिए। एक प्रणाली एक दो स्तरीय वास्तुकला (क्लाइंट-डीबीएमएस) या तीन स्तरीय (क्लाइंट-सर्वर-डीबीएमएस) हो सकती है। दोनों विकल्पों में उनके पेशेवरों और विपक्ष दोनों हैं। यदि सिस्टम में द्वि-स्तरीय वास्तुकला है, तो ऐसे क्षण के रूप में सर्वर को प्रशासित करने की आवश्यकता को बाहर रखा गया है। DBMS उपकरण डेटा संग्रहण और उस तक पहुंच अधिकारों के वितरण को व्यवस्थित करते हैं। लेकिन इसका माइनस क्लाइंट साइड (तथाकथित "मोटी" क्लाइंट) पर डेटा प्रोसेसिंग का संगठन है। डेटा प्राप्त करने के लिए, ग्राहक को डीबीएमएस तक सीधे पहुंच दी जाती है, जिससे डेटा तक अनधिकृत पहुंच और उनकी अखंडता का उल्लंघन हो सकता है।

थ्री-टियर आर्किटेक्चर आपको सुरक्षा प्रणाली की अधिक लचीली संरचना को व्यवस्थित करने और डीबीएमएस की क्षमताओं तक सीमित नहीं होने देता है, डेटा के अनधिकृत उपयोग को बाहर करने और क्लाइंट द्वारा किए गए डेटा के साथ संचालन को नियंत्रित करने वाले सर्वर द्वारा किए गए परिवर्तनों की निगरानी करने की अनुमति देता है।

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

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

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

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

पूर्वगामी के आधार पर, हम ECM प्रणाली चुनने के लिए निम्नलिखित व्यावहारिक सिफारिशें तैयार कर सकते हैं:

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

एक अच्छा विकल्प है!