आप कितनी बार यह कथन सुनते हैं कि CRM निर्माता द्वारा दिया गया सहसंबंध नियम काम नहीं करता है और उत्पाद को स्थापित करने के तुरंत बाद हटा दिया जाता है या अक्षम कर दिया जाता है? सूचना सुरक्षा घटनाओं में, कोई भी विभाग जो डिएगो को समर्पित है, इस मुद्दे को एक या दूसरे तरीके से संबोधित करता है।

आइए एक मौका लें और समस्या का समाधान खोजने की कोशिश करें।



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

अनजाने में आप खुद से पूछते हैं कि क्या वास्तव में सब कुछ इतना बुरा है और इस गॉर्डियन गाँठ को नहीं काटा जा सकता है? क्या अभिव्यक्ति "सहसंबंध नियम जो बॉक्स से बाहर काम करते हैं" केवल एक विपणन नारा है जिसकी लागत कुछ भी नहीं है?

एक लेख आपको दिलचस्पी ले सकता है अगर:

• आप पहले से ही कुछ तरह के सीएमजी समाधान के साथ काम कर रहे हैं।
• बस इसे लागू करने की योजना है।
• हमने ईएलके स्टैक, या कुछ और के आधार पर लाठी और सहसंबंधों के साथ हमारे एसईएम का निर्माण करने का निर्णय लिया।

लेख किस बारे में होंगे

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

मुझे तुरंत यह कहना चाहिए कि यह इस लेख को तकनीकी विशेषज्ञों द्वारा विशेषता के रूप में देखा जा सकता है: "पानी", "कुछ भी नहीं"। सब कुछ ऐसा है, लेकिन काफी नहीं है। किसी भी मुश्किल काम से निपटने से पहले, मैं सबसे पहले यह जानना चाहता हूं कि यह क्यों पैदा हुआ और इसका समाधान हमें क्या देता है।

प्रस्तुत किए जाने वाले मुद्दों की पूरी श्रृंखला की बेहतर समझ के लिए, मैं लेखों की पूरी श्रृंखला की सामान्य संरचना दूंगा:

• अनुच्छेद 1: यह अनुच्छेद। आइए समस्या के बयान के बारे में बात करते हैं और यह समझने की कोशिश करते हैं कि हमें आम तौर पर नियमों की आवश्यकता क्यों है "सहसंबंध नियम जो बॉक्स से बाहर काम करते हैं।" लेख प्रकृति में वैचारिक होगा और, यदि यह पूरी तरह से उबाऊ हो जाता है, तो आप इसे छोड़ सकते हैं। लेकिन, मैं ऐसा करने की सलाह नहीं देता, क्योंकि भविष्य के लेखों में मैं अक्सर इसका उल्लेख करूंगा। यहां हम उन मुख्य समस्याओं पर चर्चा करेंगे जो हमारे रास्ते में खड़ी हैं, और उन्हें हल करने के तरीके।
• लेख २: हुर्रे! यह वह जगह है जहां हम समस्या को हल करने के लिए प्रस्तावित दृष्टिकोण का पहला विवरण प्राप्त करते हैं। आइए हम बताते हैं कि हमारी सुरक्षित सीएमजी सूचना प्रणाली को कैसे "देखना" चाहिए। आइए बात करते हैं कि घटनाओं को सामान्य करने के लिए आवश्यक फ़ील्ड का सेट क्या होना चाहिए।
• अनुच्छेद 3: हम घटनाओं को वर्गीकृत करने की भूमिका का वर्णन करते हैं और घटनाओं को सामान्य बनाने की कार्यप्रणाली को इसके आधार पर कैसे बनाया जाता है। हम दिखाते हैं कि आईटी ईवेंट आयोजनों से कैसे भिन्न होते हैं और उनके वर्गीकरण के अलग-अलग सिद्धांत क्यों होने चाहिए। हम इस पद्धति के काम का जीवंत उदाहरण देते हैं।
• अनुच्छेद 4: हमारी स्वचालित प्रणाली बनाने वाली संपत्तियों पर एक नज़र डालें और देखें कि वे नियमों के प्रदर्शन को कैसे प्रभावित करते हैं। हम यह सुनिश्चित करेंगे कि यह उनके साथ इतना सरल नहीं है: उन्हें पहचानने और लगातार अद्यतित रखने की आवश्यकता है।
• अनुच्छेद 5: वह जिसके लिए सब कुछ शुरू किया गया था। हम सहसंबंध के नियमों को लिखने के दृष्टिकोण का वर्णन करते हैं, जो पिछले लेखों में बताई गई हर चीज पर आधारित था।

समस्या कथन और यह महत्वपूर्ण क्यों है

आइए, सरल शब्दों में, हमारे कार्य को रेखांकित करने का प्रयास करें: “मैं, एक ग्राहक के रूप में, जिसने एक CRM समाधान खरीदा था, नियम आधार को अद्यतन करने के लिए सब्सक्राइबर और समर्थन के लिए निर्माता (और कभी-कभी इंटीग्रेटर) को भुगतान करता है, मैं तुरंत स्थापित किए गए सहसंबंध नियमों के साथ आपूर्ति करना चाहता हूं। मेरे टीआरएम में उपयोगी होगा। ” मेरे लिए, इतनी अच्छी इच्छा, किसी भी वास्तु या संरचनात्मक तकनीकी सीमाओं से बोझिल नहीं।

और अब, ध्यान दें, मान लें कि हमने सभी समस्याओं को पहले ही हल कर लिया है और हमारा कार्य पहले ही पूरा हो चुका है। यह हमें क्या देता है?

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

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

मुझे लगता है कि यह बहुत महत्वपूर्ण है, क्योंकि बाद में वर्णित की जाने वाली हर चीज को लगभग किसी भी मौजूदा और परिपक्व डिएगो में लागू किया जा सकता है।

पर्याप्त रूप से गीत, तब हम अपनी समस्या को हल करने में आने वाली समस्याओं के बारे में अधिक विस्तार से बात करेंगे।

हमारे सामने चुनौतियां हैं

उपरोक्त समस्या के समाधान की तलाश में, आइए देखें कि हमें किन समस्याओं का सामना करना पड़ता है। मुख्य समस्याओं पर प्रकाश डालने से समस्याओं की बेहतर समझ हो जाएगी, साथ ही उन्हें हल करने के लिए एक व्यवस्थित दृष्टिकोण विकसित होगा।
हम जिन समस्याओं का सामना करते हैं वे एक स्नोबॉल हैं, जिनमें से प्रत्येक नाटकीय रूप से स्थिति को बढ़ाता है। इन समस्याओं में से कई "सहसंबंध नियम जो बॉक्स से बाहर काम करते हैं" के निर्माण की ओर ले जाती हैं बेहद मुश्किल है।

सामान्य तौर पर, समस्याओं को निम्नलिखित चार बड़े ब्लॉकों में विभाजित किया जाता है:

1. "दुनिया" के मॉडल के परिवर्तन से जुड़े सामान्यीकरण के दौरान डेटा की हानि।
2. घटनाओं को सामान्य करने के लिए स्पष्ट और सार्वभौमिक रूप से स्वीकृत नियमों का अभाव।
3. संरक्षण की वस्तु का निरंतर "उत्परिवर्तन" - हमारी स्वचालित प्रणाली।
4. सहसंबंध के नियम लिखने का अभाव।

आइए अब हम इन मुद्दों की अधिक विस्तार से जाँच करें।

विश्व मॉडल परिवर्तन

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


ऊपर वर्णित उदाहरण में, हम एक क्लासिक समस्या का निरीक्षण करते हैं, जिसमें मूल "वैचारिक मॉडल" ( Sovtov B. Ya।, Yakovlev S. A., System Modeling ) को विस्तार में खोते हुए दूसरे मॉडल में सरलीकरण द्वारा बदल दिया जाता है।
वास्तव में सॉफ्टवेयर या हार्डवेयर द्वारा उत्पन्न घटनाओं की दुनिया में भी ऐसा ही होता है।

एक स्पष्टीकरण यहाँ सेवा कर सकता है जो हमारे विषय क्षेत्र से पहले से ही एक सरलीकृत चित्र है:

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

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


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

इस समस्या का एक अच्छा संकेतक है, अगर अजीब नहीं है, तो ग्राहक उपकरण स्ट्रिंग, डेटाफ़ील्ड, या कुछ और जैसे फ़ील्ड। ये फ़ील्ड एक प्रकार के "डंप" का प्रतिनिधित्व करते हैं, जहाँ वे डेटा डालते हैं जो उन्हें नहीं पता होता है कि कहाँ रखा जाना है, या जब अन्य सभी उपयुक्त फ़ील्ड केवल बाढ़ में हैं।

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

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

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

घटना सामान्यीकरण पद्धति

यह याद रखना महत्वपूर्ण है कि कौन और कैसे घटनाओं को सामान्य करता है, क्योंकि यह एक महत्वपूर्ण भूमिका निभाता है। स्रोत का हिस्सा सीधे ही CRM समाधान के विकासकर्ता द्वारा समर्थित है, भाग वह इंटीग्रेटर है जिसने आपके लिए CRM का कार्यान्वयन किया है, और भाग आपका है। यह वह जगह है जहां अगली समस्या हमें इंतजार कर रही है: प्रत्येक प्रतिभागी अपने तरीके से घटना स्कीमा के क्षेत्रों के अर्थ की व्याख्या करता है और इसलिए विभिन्न तरीकों से सामान्यीकरण करता है। इस प्रकार, विभिन्न प्रतिभागी अलग-अलग क्षेत्रों में डेटा के समान डेटा को विघटित कर सकते हैं। बेशक, कई क्षेत्र हैं, जिनमें से नाम दोहरी व्याख्या की अनुमति नहीं देता है। मान लीजिए src_ip या dst_ip, लेकिन उनके साथ भी कठिनाइयाँ हैं। उदाहरण के लिए, नेटवर्क घटनाओं में, क्या src_ip को dst_ip में बदलना आवश्यक है जब एक ही सत्र के भीतर आने वाले और बाहर जाने वाले कनेक्शन को सामान्य किया जाए?

उपरोक्त के आधार पर, समर्थन स्रोतों के लिए एक स्पष्ट कार्यप्रणाली बनाने की आवश्यकता है, जिसके ढांचे के भीतर यह स्पष्ट रूप से इंगित किया जाएगा:

1. क्या जरूरत है के लिए सर्किट के क्षेत्र क्या हैं।
2. कौन से डेटा किस फील्ड के अनुरूप हैं।
3. प्रत्येक प्रकार की घटना के ढांचे के भीतर हमारे लिए क्या जानकारी महत्वपूर्ण है।
4. खेतों में भरने के नियम क्या हैं।

संरक्षण की वस्तु का मॉडल और उसका उत्परिवर्तन

कार्य के समाधान के हिस्से के रूप में, सुरक्षा का उद्देश्य हमारी स्वचालित प्रणाली (एएस) है। हां, यह GOST 34.003-90 की परिभाषा में एयू है, इसकी सभी प्रक्रियाओं, लोगों और प्रौद्योगिकियों के साथ। यह एक महत्वपूर्ण बिंदु है, हम निम्नलिखित लेखों में बाद में इस पर लौटेंगे।

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

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

सहसंबंध नियम विकसित करने की पद्धति

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

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

अंत में

लेखों की इस श्रृंखला के एक भाग के रूप में, हम यह समझने की कोशिश करेंगे कि सहसंबंध नियमों को किस प्रकार से कार्य करना है।

समस्या को हल करने के लिए हमें निम्नलिखित समस्याओं का सामना करना पड़ेगा:

1. सामान्यीकरण स्तर पर "दुनिया" मॉडल के परिवर्तन के दौरान डेटा हानि।
2. एक सामान्यीकरण पद्धति की स्पष्ट परिभाषा का अभाव।
3. लोगों और प्रक्रियाओं के प्रभाव में संरक्षण की वस्तु का स्थायी परिवर्तन।
4. सहसंबंध नियम लिखने के लिए कार्यप्रणाली का अभाव।

इन समस्याओं में से कई सही घटना योजना के निर्माण के विमान में निहित हैं - खेतों का एक सेट और घटनाओं को सामान्य करने की प्रक्रिया - सहसंबंध नियमों की नींव। समस्याओं का एक और हिस्सा संगठनात्मक और पद्धतिगत तरीकों से हल किया जाता है। यदि हम इन समस्याओं का समाधान खोजने का प्रबंधन करते हैं, तो बॉक्स नियमों से बाहर काम करने की अवधारणा का व्यापक सकारात्मक प्रभाव पड़ेगा और यह एक हद तक ही सही, CRM निर्माताओं द्वारा निर्धारित विशेषज्ञता को बढ़ा देगा।

आगे क्या है? अगले लेख में, हम "दुनिया" मॉडल के परिवर्तन के दौरान डेटा हानि से निपटने की कोशिश करेंगे और सोचेंगे कि हमारे कार्य के लिए आवश्यक फ़ील्ड का सेट कैसा दिखना चाहिए - एक आरेख।

---

लेखों की श्रृंखला:

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 1: शुद्ध विपणन या एक बेकार समस्या? ( यह लेख )

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 2. डेटा स्कीमा "दुनिया" मॉडल के प्रतिबिंब के रूप में

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 3.1। घटना वर्गीकरण

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 3.2। घटना सामान्यीकरण पद्धति

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 4. सहसंबंध नियमों के संदर्भ के रूप में सिस्टम मॉडल

सिएम गहराई: आउट-ऑफ-द-बॉक्स सहसंबंध। भाग 5. सहसंबंध नियम विकसित करने की पद्धति