अराजकता के खिलाफ स्वचालन

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

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

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

यूनिवर्सल प्रारूप

ग्राहक ने कंपनी की सभी शाखाओं से रिपोर्ट के लिए डेटा एकत्र करने का कार्य निर्धारित किया है। आपदा के पैमाने को समझने के लिए, स्व-निर्मित और राक्षस दोनों जैसे SAP और, बेशक, 1C - सहित दर्जनों प्रणालियां हैं, जहां इसके बिना।

एक रिपोर्ट में, डेटा: बुककीपिंग, रिपेयरमेन, पीआर विशेषज्ञ, आपात स्थिति मंत्रालय, मौसम विज्ञानी प्रतिच्छेद कर सकते हैं।

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

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

हमारी जिद्दी योजना यह थी:

1. प्रत्येक रिपोर्ट की संरचना और इसके प्रसारण के नियमों का वर्णन करें;
2. हम शाखाओं को नियमों के अनुसार ईमेल द्वारा दस्तावेज भेजने के लिए सिस्टम स्थापित करने के लिए आवश्यकताओं को कम करते हैं। जहां सिस्टम नहीं हैं - भेजना, पहले की तरह, हाथ से;
3. हम एक कार्यक्रम विकसित कर रहे हैं:
   
   • आने वाले मेल से कुछ दस्तावेजों का चयन करता है;
   • उनसे डेटा निकालता है;
   • डेटाबेस में निकाले गए डेटा को लिखते हैं, साथ ही नियमों के उल्लंघनकर्ताओं को "पिटाई" करते हैं।
   
   

कार्यान्वयन

संगठनात्मक मामले

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

समस्या एक

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

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

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

दूसरी समस्या

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

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

विकसित सबसिस्टम

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

विन्यासक

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

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



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



अन्य उपयोगी सेटिंग्स में सॉल्व्ड सेंडर्स की लिस्ट, डॉक्यूमेंट टाइप (एक्सेल / वर्ड) और डेटा एक्सपोर्ट करने का रास्ता शामिल है।

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

मेल प्राप्तकर्ता

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

2 सुरक्षा प्रश्न हैं:

1. यदि डेटा दूसरी शाखा को भेजा जाता है तो क्या होगा?
2. क्या होगा यदि डेटा हमलावरों द्वारा भेजा जाता है?

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

दूसरा SPF का उपयोग कर रहा है।

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

वर्ड और एक्सेल को पार्स करने के लिए लगभग सभी पुस्तकालयों की समर्थित संस्करणों पर गंभीर सीमाएँ हैं, इसलिए एक शुरुआत के लिए दस्तावेज़ को परिवर्तित करना होगा। लिबरे ऑफिस इस समस्या को पांच हल करता है।

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

1. हम विन्यासकर्ता (शब्द / एक्सेल, प्रेषक ...) से बुनियादी विशेषताओं के अनुसार टेम्पलेट्स की एक सरणी फ़िल्टर करते हैं;
2. शेष टेम्पलेट्स के साथ दस्तावेज़ चलाएं;
3. यदि टेम्पलेट पाया जाता है, तो हम डेटा निकालते हैं और इसे रिपॉजिटरी में स्थानांतरित करते हैं।

परिणाम

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

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

1. हमें शाखाओं में अंदर की व्यवस्था नहीं मिली;
2. औपचारिकता और उनके प्रसारण के लिए रिपोर्टों और नियमों की एक संरचना को मंजूरी दी;
3. एक्सेल और वर्ड दस्तावेजों के रूप में सभी प्रणालियों के लिए आम तौर पर उपलब्ध आउटपुट प्रारूपों के टेम्पलेट;
4. डेटा डिलीवरी का सबसे आम तरीका चुना - ईमेल।

और दो मुख्य नुकसान:

• कम डेटा वितरण की गति।
• डेटा पैकेट का आकार एक नियमित ईमेल अनुलग्नक के आकार से अधिक नहीं होना चाहिए।