👩‍👩‍👦‍👦 👼🏻 🧠 सेलोनिस द्वारा एसएपी प्रक्रिया खनन के लिए डेटा कैसे तैयार किया जाए 👩🏼‍🏭 🕰️ 🚀

एक उदाहरण के रूप में एक आईटी सेवा प्रबंधन प्रणाली (ITSM) से डेटा का उपयोग करना।

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

सेलॉन द्वारा SAP प्रक्रिया मिनट में डेटा मॉडल

सेलोनिस उपकरण द्वारा एसएपी प्रक्रिया खनन में डेटा संरचना काफी सरल है:

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

चित्रा 1. कार्यवाही खनन में डेटा मॉडल: एक घटना तालिका और प्रक्रिया उदाहरणों के लिए एक संदर्भ

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

नीचे हम डेटा मॉडल के इन दो घटकों में से प्रत्येक पर करीब से नज़र डालेंगे।

एक "ईवेंट टेबल" (उर्फ "ईवेंट लॉग") में कम से कम तीन आवश्यक कॉलम होते हैं:

एक प्रक्रिया पहचानकर्ता प्रत्येक प्रक्रिया उदाहरण (उदाहरण के लिए, एक संदर्भ, घटना या कार्य संख्या) के लिए एक अद्वितीय कुंजी है। चित्र 2 में उदाहरण में, यह "CASE_ID" कॉलम है।
गतिविधि। यह प्रक्रिया में कदम का नाम है - किसी प्रकार की घटना जिसमें हम रुचि रखते हैं। यह गतिविधियों से है कि प्रक्रिया ग्राफ (कॉलम "ईवेंट") से बना होगा।
घटना का टाइमस्टैम्प (कॉलम "टाइमस्टैम्प")।

चित्र 2. उदाहरण तालिका

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

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

चित्र 3. दो टाइमस्टैम्प के साथ उदाहरण तालिका

इस तालिका के अन्य सभी कॉलम वैकल्पिक हैं। तीन आवश्यक स्तंभों का उपयोग करके प्रक्रिया ग्राफ को सफलतापूर्वक बहाल किया जा सकता है, लेकिन यह महसूस करना मुश्किल होगा कि कुछ गायब है। इसलिए, यह अत्यधिक अनुशंसा की जाती है कि आप अपने आप को केवल वक्ताओं के न्यूनतम सेट तक सीमित न करें।

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

सब कुछ जगह पर रहने दो

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

लाइसेंस के बारे में थोड़ा सा

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

संदर्भ

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

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

यह करने के लिए काफी सरल है:

SAP HANA में एक तालिका बनाई गई है।
तालिका को "आयात डेटा" बटन का उपयोग करके सामान्य डेटा मॉडल में जोड़ा जाता है।

चित्र 4. किसी मौजूदा डेटा मॉडल में एक तालिका या फ़ाइल आयात करें
कुंजी (या कुंजियाँ) चित्रमय इंटरफ़ेस में इंगित की जाती है, जिसके द्वारा नई निर्देशिका घटना तालिका और / या अन्य निर्देशिकाओं से जुड़ी होती है। ऐसा करने के लिए, बस आइकन पर क्लिक करें एक तालिका में और फिर इसी पर एक और तालिका में।

चित्रा 5. एक मध्यस्थ क्षेत्र द्वारा डेटा मॉडल में तालिकाओं को जोड़ना (इस मामले में, CASE_ID)
"स्थिति" मेनू में, "स्रोत से पुनः लोड करें" बटन पर क्लिक करें। इस प्रक्रिया में आमतौर पर कुछ सेकंड लगते हैं।

चित्र 6. स्रोत से डेटा मॉडल को पुनः लोड करना

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

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

सीए तालिका: प्रक्रिया उदाहरण संदर्भ

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

चित्र 7. उदाहरण CA तालिका

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

चित्रा 8. स्वचालित रूप से उत्पन्न घटना श्रृंखला (सीए) तालिका

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

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

चित्रा 9. सिंथेटिक उदाहरण रिपोर्ट "सीए देखें"

डेटा मॉडल में अपनी प्रक्रिया संदर्भ कैसे जोड़ें:

SAP HANA में एक तालिका बनाई गई है।
तालिका को "आयात डेटा" बटन का उपयोग करके सामान्य डेटा मॉडल में जोड़ा जाता है।
चित्रमय इंटरफ़ेस में, तालिका के गुणों में, आपको इसे "सीए के साथ तालिका" भूमिका सेट करने की आवश्यकता है।

चित्रा 10. प्रक्रिया उदाहरणों की निर्देशिका को इंगित करने के लिए "सीए के साथ तालिका" की भूमिका
GUI में, CA तालिका को इवेंट ID के साथ प्रोसेस ID से संबद्ध करें। यह कदम उसी तरह से किया जाता है जैसे किसी नियमित निर्देशिका के मामले में - मुख्य प्रतीक कुंजी के साथ ( ) संबंधित क्षेत्र के विपरीत।
"स्थिति" मेनू में, "स्रोत से पुनः लोड करें" बटन पर क्लिक करें।

महत्वपूर्ण नोट: CA तालिका में "CASE_ID" कॉलम (प्रत्येक मामले में, इसे अन्यथा कहा जा सकता है), जिसमें प्रक्रिया पहचानकर्ता शामिल है और इसका उपयोग इवेंट टेबल के साथ करने के लिए किया जाता है, इसमें केवल अनन्य मान होने चाहिए। यह काफी तार्किक है। और अगर किसी कारण से ऐसा नहीं होता है, तो चरण (5) में डेटा मॉडल लोड करते समय, संबंधित त्रुटि उत्पन्न होगी (घटना तालिका और सीए तालिका पर "जिन्न" ऑपरेशन करने की असंभवता के बारे में)।

परिवर्तन इतिहास से एक डेटा मॉडल बनाना

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

आईटी से क्या पूछना है?

यदि आप आईटी कर्मचारी या ITSM आधार की सेवा देने वाले विशेषज्ञ नहीं हैं, तो इस तथ्य के लिए तैयार रहें कि आपसे प्रश्न का सटीक उत्तर तैयार करने के लिए कहा जाएगा "आप क्या उतारते हैं?" या "आप हमसे क्या चाहते हैं?"

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

प्रश्न के दो संभावित उत्तर हैं "आप क्या उतारना"।

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

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

यह मुझे लगता है कि एक बेहतर विकल्प है। आप निम्न तालिका के रूप में डेटा का अनुरोध कर सकते हैं:

अपील की संख्या, घटना, कार्य (एसडी *, आईएम *, आरटी *, ...) ITSM प्रणाली (NVARCHAR) में वस्तु की पहचानकर्ता है
टाइमस्टैम्प (TIMESTAMP)
विशेषता नाम (NVARCHAR)
पुराना मान (NVARCHAR)
नया मान (NVARCHAR)
कौन बदल गया है (NVARCHAR)

वास्तव में, यह किसी भी विशेषता में परिवर्तन के इतिहास से ज्यादा कुछ नहीं है। ITSM सिस्टम के इंटरफेस में आप "इतिहास" या "जर्नल" नाम के साथ टैब पर ऐसी तालिका देख सकते हैं।

इस दृष्टिकोण के फायदे स्पष्ट हैं:

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

दूसरे विकल्प के नुकसान भी स्पष्ट हैं। और वे, यह मुझे लगता है, हल किया जा सकता है (अपूर्ण डेटा की समस्या के विपरीत):

डेटा तैयार करने के लिए एसक्यूएल स्क्रिप्ट कुछ अधिक जटिल हो जाती है - विकल्प की तुलना में जब आईटी आधार टीम आपके लिए आंशिक डेटा तैयार करती है (क्वेरी का पहला संस्करण देखें), बिना संदेह किए। हां, वह (स्क्रिप्ट) अधिक जटिल है, लेकिन वह अकेला है। मुझे लगता है कि ITSM टीम और प्रोसेस माइनिंग टीम के बीच डेटा तैयारी को साझा करना एक बुरा विचार होगा। Process Mining, , , . .
. : 10-30 / . HANA . , «» , ETL/ELT HANA (, HANA Smart Data Integration), .

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

इवेंट टेबल जनरेशन

इसलिए, बाहर निकलने पर, हमारे पास अनुरोधों, घटनाओं, कॉल, कार्यों और अन्य ITSM वस्तुओं की विशेषताओं में परिवर्तन का इतिहास है। ऐसी तालिका से, प्रक्रिया खनन डेटा मॉडल के दोनों प्रमुख घटकों को उत्पन्न करना संभव है: एक घटना तालिका और एक सीए तालिका।

परिवर्तन इतिहास के आधार पर घटनाओं को उत्पन्न करने के लिए, निम्नलिखित कार्य करें:

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

मान लीजिए कि परिवर्तन तालिका निम्नानुसार है:

CREATE COLUMN TABLE "SAP_PM"."ITSM_HISTORY" ( "CASE_ID" NVARCHAR(256), "ATTRIBUTE" NVARCHAR(256), "VALUE_OLD" NVARCHAR(1024), "VALUE_NEW" NVARCHAR(1024), "TS" TIMESTAMP, "USER" NVARCHAR(256) );

सबसे पहले, मौजूद सभी विशेषताओं की सूची देखें। यह "ओपन डेटा प्रीव्यू" मेनू में या इस तरह एक साधारण SQL क्वेरी के साथ किया जा सकता है:

 SELECT DISTINCT "ATTRIBUTE" FROM "SAP_PM"."ITSM_HISTORY";

चित्रा 11. SAP हाना स्टूडियो में ओपन डेटा पूर्वावलोकन कमांड के साथ संदर्भ मेनू

फिर हम विशेषताओं की संरचना का निर्धारण करते हैं, जिनमें से परिवर्तन हमारे लिए प्रक्रिया में एक घटना है। ऐसी सूची के लिए स्पष्ट उम्मीदवारों की सूची इस प्रकार है:

स्थिति
काम पर ले जाया गया
श्रेणी बदल दी गई है
समय सीमा का उल्लंघन हुआ
प्रतिक्रिया समय का उल्लंघन किया जाता है
संशोधन के लिए अनुरोध वापस कर दिया गया है।
पहली पंक्ति त्रुटि
कार्य समूह
प्राथमिकता

यहाँ मुख्य घटनाएँ, ज़ाहिर है, अपील / घटना \ application \ task की स्थितियों के बीच संक्रमण हैं। "स्थिति" विशेषता (VALUE_NEW) का मान हमारे लिए प्रक्रिया चरण का नाम होगा। तदनुसार, पहले सन्निकटन के रूप में एक घटना तालिका बनाना इस तरह दिख सकता है:

 CREATE COLUMN TABLE "SAP_PM"."ITSM_EVENTS" ( "CASE_ID" NVARCHAR(256) ,"EVENT" NVARCHAR(1024) ,"TS" TIMESTAMP ,"USER" NVARCHAR(256) ,"VALUE_OLD" NVARCHAR(1024) ,"VALUE_NEW" NVARCHAR(1024) ); INSERT INTO "SAP_PM"."ITSM_EVENTS" SELECT "CASE_ID" ,"VALUE_NEW" AS "EVENT" ,"TS" ,"USER" ,"VALUE_OLD" ,"VALUE_NEW" FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' ;

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

 INSERT INTO "SAP_PM"."ITSM_EVENTS" SELECT "CASE_ID" ,"ATTRIBUTE" AS "EVENT" ,"TS" ,"USER" ,"VALUE_OLD" ,"VALUE_NEW" FROM "SAP_PM"."ITSM_HISTORY" WHERE "VALUE_OLD" IS NOT NULL AND "ATTRIBUTE" IN ( '   ' ,'  ' ,'  ' ,'  ' ,'    ' ,' 1- ' ,' ' ,'') );

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

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

"VALUE_OLD" पूर्ण नहीं है
"VALUE_NEW" = 'हाँ'
आप टाइम स्टैम्प पर ध्यान केंद्रित कर सकते हैं (केवल उन घटनाओं को लें जो ऑब्जेक्ट के पंजीकरण के बाद हुई थीं)।
यदि सिस्टम खाता प्रारंभ कर रहा है, तो आप "USER" फ़ील्ड पर ध्यान केंद्रित कर सकते हैं।
आपके साथ कोई भी अन्य स्थिति आ गई है।

सीए टेबल जनरेशन

परिवर्तनों का वही इतिहास जो हमें घटनाओं के स्रोत के रूप में कार्य करता है, प्रक्रिया इंस्टेंसेस (CA टेबल्स) की निर्देशिका बनाने के लिए भी उपयोगी होगा। एल्गोरिथम समान:

1. विशेषताओं की एक सूची निर्धारित करें:

एक। उदाहरण के लिए, अपील के लेखक और उसके विभाग, काम के परिणामों के आधार पर उपयोगकर्ता की रेटिंग, समय सीमा के उल्लंघन के झंडे के आधार पर काम के दौरान न बदलें।

ख। वे बदल सकते हैं, लेकिन हम केवल कुछ बिंदुओं पर मूल्यों में रुचि रखते हैं: पंजीकरण के समय, समापन, जब भर्ती, दूसरी पंक्ति से 1 के लिए स्थानांतरण, आदि।

सी। वे बदल सकते हैं, लेकिन हम केवल संयुक्त मूल्यों (अधिकतम, न्यूनतम, मात्रा, आदि) में रुचि रखते हैं।

2. स्तंभों के वांछित सेट के साथ एक विकर्ण तालिका बनाएं। हमारे लिए ब्याज की प्रत्येक विशेषता पंक्तियों के अपने स्वयं के सेट (प्रक्रिया उदाहरणों की संख्या के अनुसार) उत्पन्न करेगी, जिसमें केवल एक कॉलम का एक मूल्य होगा, और बाकी सभी खाली (NULL) होंगे।

3. हम प्रक्रिया पहचानकर्ता द्वारा समूहीकरण का उपयोग करते हुए विकर्ण तालिका को अंतिम निर्देशिका में ध्वस्त करते हैं।

उन विशेषताओं के उदाहरण जिन्हें यह CA तालिका में रखने के लिए समझ में आता है (व्यवहार में, यह सूची अधिक लंबी हो सकती है):

सेवा
आईटी प्रणाली
लेखक
लेखक संगठन
समाधान गुणवत्ता की उपयोगकर्ता रेटिंग
काम करने के लिए रिटर्न की संख्या
जब काम पर ले जाया गया
द्वारा बनाया गया
कौन बंद हुआ
पंक्ति 1 द्वारा हल किया गया
अमान्य वर्गीकरण / मार्ग
समय सीमा
समय सीमा का उल्लंघन

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

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

सामान्य तौर पर, जब हम गुण परिवर्तन के इतिहास के आधार पर प्रक्रिया गुण बनाते हैं, तो हमारे लिए उपयोगी जानकारी का स्रोत हो सकता है:

गुण को स्वयं मानें (उदाहरण: "उपयोगकर्ता रेटिंग")
उपयोगकर्ता जिसने इसे बदल दिया है
समय बदला
उस समय जब विशेषता ने एक निश्चित मान लिया (उदाहरण: विशेषता "डेडलाइन का उल्लंघन किया गया" विशेषता मूल्य में ही दिलचस्पी नहीं है, लेकिन उस समय में जब यह उठाए गए ध्वज के बराबर में बदल जाता है - उदाहरण के लिए, 'हां' या 1)
तथ्य यह है कि विशेषता इतिहास में मौजूद है (उदाहरण: "मास घटना" मान 'हाँ' के साथ)

यह सूची, निश्चित रूप से, विशेषताओं का उपयोग करने के लिए अन्य विचारों के साथ जारी रखी जा सकती है और यह सब उनके साथ जुड़ा हुआ है।

अब जब हमने पहले ही ब्याज की संपत्तियों की सूची पर फैसला कर लिया है, तो आइए सीए तालिका बनाने के संभावित परिदृश्यों में से एक देखें। सबसे पहले, तालिका को स्तंभों के सेट के साथ बनाएं, जिन्हें हमने स्वयं के लिए परिभाषित किया है:

 CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES" ( "CASE_ID" NVARCHAR(256) NOT NULL ,"CATEGORY" NVARCHAR(256) DEFAULT NULL ,"AUTHOR" NVARCHAR(256) DEFAULT NULL ,"RESOLVER" NVARCHAR(256) DEFAULT NULL ,"RAITING" INTEGER DEFAULT NULL ,"OPEN_TIME" TIMESTAMP DEFAULT NULL ,"START_TIME" TIMESTAMP DEFAULT NULL ,"DEADLINE" TIMESTAMP DEFAULT NULL );

हमें एक अस्थायी तालिका "ITSM_CASES_STAGING" की आवश्यकता होगी, जो हमें प्रक्रिया उदाहरणों की निर्देशिका में आवश्यक संपत्ति कॉलम के लिए विशेषताओं की एक फ्लैट सूची को सॉर्ट करने की अनुमति देगा:

 CREATE COLUMN TABLE "SAP_PM"."ITSM_CASES_STAGING" LIKE "SAP_PM"."ITSM_CASES" WITH NO DATA;

यह एक विकर्ण तालिका होगी - प्रत्येक पंक्ति में केवल दो फ़ील्ड का मान होता है: "CASE_ID", अर्थात्। प्रक्रिया पहचानकर्ता, और एक एकल क्षेत्र एक प्रक्रिया संपत्ति के साथ। पंक्ति में शेष फ़ील्ड रिक्त (NULL) होंगे। अंतिम चरण में, हम आसानी से सरल एकत्रीकरण द्वारा पंक्तियों में विकर्णों को ध्वस्त करते हैं और इस तरह हमें सीए की तालिका प्राप्त होती है जो हमें चाहिए।

एक उपचार श्रेणी के लिए एक उदाहरण:

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "CATEGORY") SELECT "CASE_ID", LAST_VALUE("VALUE_NEW" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' GROUP BY "CASE_ID" ;

मान लें कि लेखक अपील के इतिहास में पहला गैर-सिस्टम उपयोगकर्ता है जो अपील करता है (आपके विशेष मामले में, मानदंड अधिक सटीक हो सकता है):

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "AUTHOR") SELECT "CASE_ID", FIRST_VALUE("USER" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "USER" != 'SYSTEM' GROUP BY "CASE_ID" ;

यदि हम मानते हैं कि हैंडलर जिसने अंतिम स्थिति "समाधान प्रस्तावित" (और समाधान को बार-बार प्रस्तुत किया जा सकता है, लेकिन केवल अंतिम निश्चित है), समस्या को सफलतापूर्वक हल कर दिया है, तो प्रक्रिया उदाहरण की इस संपत्ति को निम्नानुसार तैयार किया जा सकता है:

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RESOLVER") SELECT "CASE_ID", LAST_VALUE("USER" ORDER BY "TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '' AND "VALUE_NEW" = ' ' GROUP BY "CASE_ID" ;

उपयोगकर्ता रेटिंग (निर्णय के साथ उसकी संतुष्टि):

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "RAITING") SELECT "CASE_ID", TO_INTEGER(LAST_VALUE("VALUE_NEW" ORDER BY "TS")) FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = ' ' AND "VALUE_NEW" IS NOT NULL GROUP BY "CASE_ID" ;

पंजीकरण का समय (निर्माण) प्रचलन के इतिहास में सबसे पुराना रिकॉर्ड है:

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "OPEN_TIME") SELECT "CASE_ID", MIN("TS") FROM "SAP_PM"."ITSM_HISTORY" GROUP BY "CASE_ID" ;

प्रतिक्रिया समय सेवाओं की गुणवत्ता की एक महत्वपूर्ण विशेषता है। इसकी गणना करने के लिए, आपको यह जानना होगा कि झंडा "काम पर लिया गया" पहली बार उठाया गया था:

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "START_TIME") SELECT "CASE_ID", MIN("TS") FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = '   ' AND 'VALUE_NEW' = '' GROUP BY "CASE_ID" ;

अपील या समाधान की घटनाओं के लिए समय पर प्रतिक्रियाओं के लिए KPI की गणना करने के लिए समय सीमा का उपयोग किया जाता है। इस प्रक्रिया में, समय सीमा बार-बार बदल सकती है। KPI की गणना करने के लिए, हमें इस विशेषता के नवीनतम संस्करण को जानना होगा। यदि हम स्पष्ट रूप से ट्रैक करना चाहते हैं कि समय सीमा कैसे बदल गई है, अर्थात्, प्रक्रिया के ग्राफ पर ऐसे मामलों को प्रदर्शित करने के लिए, हमें इस विशेषता का उपयोग घटना तालिका में एक प्रविष्टि बनाने के लिए भी करना चाहिए। यह एक विशेषता का एक उदाहरण है, जो एक साथ प्रक्रिया की संपत्ति और घटना के स्रोत के रूप में कार्य करता है।

 INSERT INTO "SAP_PM"."ITSM_CASES_STAGING" ("CASE_ID", "DEADLINE") SELECT "CASE_ID", MAX(TO_DATE("VALUE_NEW")) FROM "SAP_PM"."ITSM_HISTORY" WHERE "ATTRIBUTE" = ' ' AND 'VALUE_NEW' IS NOT NULL GROUP BY "CASE_ID" ;

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

जब हमारी अस्थायी विकर्ण तालिका प्रक्रिया उदाहरणों के गुणों से भर जाती है, तो शेष सभी एकत्रीकरण करना है और अंतिम सीए तालिका प्राप्त करना है:

 INSERT INTO "SAP_PM"."ITSM_CASES" SELECT "CASE_ID" ,MAX("CATEGORY") ,MAX("AUTHOR") ,MAX("RESOLVER") ,MAX("RAITING") ,MAX("OPEN_TIME") ,MAX("START_TIME") ,MAX("DEADLINE") FROM "SAP_PM"."ITSM_CASES_STAGING" GROUP BY "CASE_ID" ;

उसके बाद, हमें अब अस्थायी तालिका में डेटा की आवश्यकता नहीं है। प्रक्रिया खनन में डेटा मॉडल को अपडेट करने के लिए नियमित आधार पर उपरोक्त प्रक्रिया को जारी रखने के लिए तालिका को ही छोड़ा जा सकता है:

 DELETE FROM "SAP_PM"."ITSM_CASES_STAGING";

पायलट प्रोजेक्ट के लिए CSV फ़ाइलों को तैयार करने और उनकी सफाई के लिए टिप्स

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

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

निर्यात करते समय फ़ाइल के लिए अनुशंसित प्रारूप आवश्यकताएं:

फ़ाइल प्रारूप: CSV
एन्कोडिंग: UTF8
फील्ड सेपरेटर: आपके लिए सुविधाजनक कोई भी चरित्र। उदाहरण के लिए, "|" या "^" या "~"। पसंद का तर्क सरल है - हमें उस स्थिति से बचने की कोशिश करनी चाहिए जब डेटा में "विभाजन" निहित हो।
खेतों के मूल्य से विभाजक को निकालना आवश्यक है। हां, आप कह सकते हैं कि इसके लिए, वास्तव में, उद्धरण चिह्न हैं। लेकिन, जैसा कि अनुभव दिखाता है, उद्धरण चिह्नों के साथ, बहुत सारी समस्याएं पैदा होती हैं। सामान्य तौर पर, आइए क्षेत्र मानों से विभाजक वर्ण को हटा दें (या प्रतिस्थापित करें)। आपकी पायलट परियोजना इस तरह की अशुद्धि से अधिक पीड़ित नहीं होगी, लेकिन डेटा तैयार करने के लिए समय काफ़ी बचत होती है।
उद्धरण चिह्न: फ़ील्ड मान से सभी उद्धरण चिह्न हटा दें। उद्धरण चिह्नों को अक्सर कंपनी के नामों में पाया जाता है - कहते हैं, कलिंका एलएलसी। लेकिन ऐसे विकल्प हैं: एमपीजेड कलिंका एलएलसी। और अब यह बड़ी मुश्किल है। फ़ील्ड मानों में उद्धरण चिह्नों को या तो "\" प्रतीक के साथ होना चाहिए, या हटा दिया जाना चाहिए, कुछ और के साथ। यह केवल इसे हटाने के लिए सबसे विश्वसनीय है। मैदानी मूल्य को इससे अधिक नुकसान नहीं होगा।
कैरिज ट्रांसफर: सभी CHAR (10) और CHAR (13) अक्षर को मानों से हटा दें। अन्यथा, सीएसवी से आयात असंभव होगा।

यदि हम खाते के बिंदुओं (4) + (5) + (6) को ध्यान में रखते हैं, तो यह चयन में निम्नलिखित निर्माण का उपयोग करने के लिए समझ में आता है:

 REPLACE(REPLACE(REPLACE(REPLACE("COLUMN", '|', ';'), '"', ''), CHAR(13), ' '), CHAR(10), ' ') as "COLUMN"

इसके अलावा, जब CSV फाइलें तैयार हो जाती हैं, तो उन्हें एक फ़ोल्डर में HANA सर्वर में कॉपी करने की आवश्यकता होती है, जो फाइलों को आयात करने के लिए सुरक्षित घोषित किया जाता है (उदाहरण के लिए, / usr / sap / HDB / आयात)। स्थानीय CSV फ़ाइल से HANA में डेटा आयात करना एक त्वरित प्रक्रिया है, बशर्ते कि फ़ाइल "साफ" हो।

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

आयात करने से पहले CSV फ़ाइलों की जाँच करें और यदि वे मौजूद हैं (और वे ९९% की संभावना के साथ) समस्या वाले क्षेत्रों को खोजें, तो आप निम्न आदेशों का उपयोग कर सकते हैं:

1. फ़ाइल के आरंभ में BOM वर्ण की जाँच करें:

फ़ाइल data.csv

यदि कमांड का परिणाम इस प्रकार है: "UTF-8 यूनिकोड (BOM के साथ) पाठ", इसका मतलब है कि एन्कोडिंग UTF8-BOM है और आपको फ़ाइल से BOM वर्ण को निकालने की आवश्यकता है। आप इसे इस प्रकार हटा सकते हैं:

sed -i '1s / ^ \ xEF \ xBB \ xBF //' data.csv

2. कॉलम की संख्या फ़ाइल की प्रत्येक पंक्ति के लिए समान होनी चाहिए:

cat data.csv | awk -F »;" '{प्रिंट NF}' | सॉर्ट | uniq

या इस तरह:

$ i में (ls * .csv); $ इको करो; बिल्ली $ मैं | awk -F '' '{प्रिंट एनएफ}' | सॉर्ट | uniq -c; गूंज; किया;

बदलें '?' आपके मामले में क्षेत्र विभाजक क्या है के लिए पैरामीटर एफ में।
इन आदेशों के परिणामस्वरूप, आपको प्रत्येक पंक्ति में कॉलम की संख्या से पंक्तियों का वितरण मिलता है। आदर्श रूप में, आपको कुछ इस तरह से मिलना चाहिए:

EKKO.csv
79536 200

यहां फ़ाइल में 79536 लाइनें हैं, और उन सभी में 200 कॉलम हैं। स्तंभों की एक अलग संख्या के साथ कोई पंक्तियाँ नहीं हैं। ऐसा होना चाहिए।

और यहाँ एक गलत परिणाम का एक उदाहरण है:

LFA1.csv
73636 180
1 १ 7१

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

cat data.csv | awk -F "" '{if (NF! = 180) {प्रिंट $ 0}}'

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

3. यदि उद्धरण चिह्न अप्रभावित हैं और इस समस्या को हल नहीं कर सकते हैं, तो आप फ़ाइल से सभी उद्धरण चिह्न हटा सकते हैं:

sed -i 's / "// g' data.csv

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

4. खाली खेत

एक ऐसी स्थिति का सामना करना पड़ा जहाँ डेटा के सफल आयात को इस क्षेत्र में खाली क्षेत्र मानों द्वारा रोका गया था:

? ""

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

sed -i's /? "" /; NULL / g ' data.csv

(विकल्प "अपने विभाजक विकल्प के लिए?")

5. यह डेटा में "गंदे" संख्या स्वरूपों के लिए उपयोगी हो सकता है:

; "0" (संख्या में एक स्थान होता है)
; "100.10-" (संकेत "-" संख्या के बाद)
बुगाटी 3/4 "300 क्रेन - एक इंच आयाम एक दोहरे उद्धरण चिह्न द्वारा इंगित किया जाता है - और यह स्वचालित रूप से निर्यात करते समय अप्रकाशित उद्धरण चिह्नों की समस्या की ओर जाता है।

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

निष्कर्ष

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

डेटा स्वामी से परिवर्तन इतिहास का अनुरोध करना
अपलोड की जाँच और सफाई (CSV फ़ाइलों की तैयारी)
एसएपी हाना के लिए आयात
इवेंट टेबल बिल्डिंग
एक सीए तालिका (प्रक्रिया संदर्भ) का निर्माण

और, वास्तव में, यह वह जगह है जहां डेटा मॉडल की तैयारी शुरू होती है और सबसे दिलचस्प हिस्सा शुरू होता है - प्रोसेस माइनिंग। यदि आपके पास प्रक्रिया खनन परियोजना के कार्यान्वयन के दौरान कोई प्रश्न है, तो टिप्पणियों में लिखने के लिए स्वतंत्र महसूस करें, मुझे मदद करने में खुशी होगी। अ छा!

फेडोर पावलोव, एसएपी सीआईएस मंच विशेषज्ञ