📌 🥤 ⛽️ स्वचालन वी.एस. कैओस 👩🏾‍✈️ 👨‍🎓 😏

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

सामान्य उद्देश्य प्रारूप

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

एक रिपोर्ट में डेटा हो सकता है: एकाउंटेंट, मरम्मत करने वाले, पीआर प्रबंधक, EMERCOM, मौसम विज्ञानी।

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

दृष्टिकोण विकल्प का उपयोग फ़ाइल स्वरूपों - xlsx / docx द्वारा किया गया था। यहां तक कि विरासत सॉफ्टवेयर इन प्रारूपों के लिए डेटा अपलोडिंग का समर्थन करता है। कम से कम कॉपी-पेस्ट शाखाओं के लिए एक अंतिम स्टैंड हो सकता है।

तो हमारी राय थी:

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

ईमेल इनबॉक्स से सही दस्तावेज़ लेता है;
दस्तावेजों से डेटा निकालता है;
डीबी को निकाले गए डेटा लिखते हैं, और नियमों के उल्लंघनकर्ताओं को दंडित करते हैं।

कार्यान्वयन

गैर-विकास के मुद्दे

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

पहला अंक

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

समाधान - तीन-चरणीय सत्यापन का कार्यान्वयन:

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

दूसरा मुद्दा

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

फीडबैक एक समाधान बन गया। सॉफ़्टवेयर स्वचालित रूप से शेड्यूल उल्लंघन के मामले में शाखा में जिम्मेदार व्यक्तियों को सूचित करता है।

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

विकसित मॉड्यूल

टेम्प्लेट कॉन्फ़िगरेशन टूल की रिपोर्ट करें, जो वर्णन करता है:

एक रिपोर्ट की पहचान करने की विशेषताएं;
संचरण नियम;
डेटा निष्कर्षण एल्गोरिथ्म;
अन्य गुण जैसे कोड का पथ जो डेटा को मान्य और संग्रहीत करता है।

एक ईमेल एप्लिकेशन जो एक पृथक भंडारण (सैंडबॉक्स) में संलग्नक को स्थानांतरित करता है और पत्र से संबंधित जानकारी संग्रहीत करता है;

अनुलग्नक पार्सर जो रिपोर्ट की पहचान करता है और डेटा को निकालता है।

कॉन्फ़िगरेशन उपकरण

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

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

हमने "स्लॉट" के लिए सरल तुलना तर्क जोड़ा: "बराबर", "असमान", "अधिक", "कम", और इसी तरह। एक्सेल रिपोर्ट के लिए उदाहरण: A2-E4 की सीमा में, सेल टेक्स्ट "दैनिक उपकरण लोडिंग रिपोर्ट" के बराबर होना चाहिए।

इसी तरह से हमने डेटा की शुरुआत और अंत के लिए खोज क्षेत्र को कॉन्फ़िगर किया है।

नीचे डेटा समाप्ति के लिए खोज स्थिति का एक उदाहरण है: "एक पंक्ति में 2 खाली लाइनें"।

कुछ अन्य सेटिंग्स: अनुमत प्रेषकों की एक सूची, एक दस्तावेज़ प्रकार (एक्सेल / वर्ड), डेटा निर्यात के लिए एक पथ।

आउटपुट JSON संरचना (टेम्पलेट) है जो रिपोर्ट का वर्णन करती है।

ईमेल आवेदन

यह एप्लिकेशन ईमेल इनबॉक्स रीडर है जो सैंडबॉक्स में सभी अटैचमेंट डालता है, ईमेल विशेषताओं को बचाता है, संलग्नक को पार्सिंग कतार में सेट करता है।

हमने 2 सुरक्षा समस्याओं का सामना किया है:

क्या होगा यदि रिपोर्ट में शाखा का नाम गलती से (या नहीं) दूसरे शाखा के नाम के साथ प्रतिस्थापित किया गया है?
क्या होगा अगर घुसपैठियों द्वारा रिपोर्ट भेजी जाती है?

पहला अंक शाखा-प्रेषक के ईमेल पते और रिपोर्ट निकाय में निर्दिष्ट शाखा नाम से हल किया जाता है।

एसपीएफ़ का उपयोग करके दूसरा मुद्दा हल किया जाता है।

अटैचमेंट पार्सर

लगभग सभी वर्ड और एक्सेल पार्सिंग लाइब्रेरी केवल कुछ निश्चित संस्करणों / एक्सटेंशन का समर्थन करते हैं। इसीलिए हमने फ़ाइलों को एक प्रारूप में लाने के लिए "लिब्रे ऑफिस" रूपांतरण का उपयोग करने का निर्णय लिया। उदाहरण इनपुट्स के लिए: odt, doc, docx (2007, 2010, 2013) ... docx (2016) में कनवर्ट करें।

रूपांतरण के बाद:

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

फिर से शुरू

हमने इसे बनाया!

दो महीने के श्रमसाध्य काम के बाद, प्रधान कार्यालय ने नियमित आधार पर सभी शाखाओं से रिपोर्ट के लिए डेटा प्राप्त करना शुरू कर दिया।

डेटा की गुणवत्ता और पूर्णता अभूतपूर्व रूप से बेहतर हो जाती है जो पहले थी। कार्यान्वित सॉफ्टवेयर ने मानव संसाधन जारी किए हैं जो वर्ष के अंत तक परियोजना लागत का भुगतान करते हैं।

खुद के लिए, हमने सीखा कि एकीकरण प्रक्रिया हमेशा दर्दनाक नहीं होती है और इसने सफलता के मुख्य पहलुओं की पहचान की है:

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

अंतिम शब्द के रूप में, इस दृष्टिकोण में दो मुख्य कमियां हैं:

कम डेटा वितरण की गति;
डेटा पैकेज का आकार औसत ईमेल अनुलग्नक की तुलना में बड़ा नहीं होना चाहिए।

स्वचालन वी.एस. कैओस