ईआरपी विकास

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

सबसे पहले, यह आवश्यक था कि सामान्य उपकरण की आपूर्ति के बजाय क्या था, फ़ायरवॉल मॉन्ट्रियल में खरीदा गया था, और मैंने कैलिफोर्निया में दो सर्वरों का आदेश दिया। ओन्टारियो, टोरंटो, फ्रैंकफर्ट, पीटर में ओन्टारियो (आप खुद अपने जोखिम पर सीमा पार करते हैं) से उन्हें हटा दिया। हार्डवेयर को कई मापदंडों के अनुसार चुना गया था: एक डेटाबेस जिसमें दूसरे प्रोसेसर को जोड़ने की क्षमता होती है, 96GB तक मेमोरी और 16 3.5 "ड्राइव तक। 1U सॉफ्टवेयर सर्वर में पहले से ही दो प्रोसेसर और 32GB होते हैं। सॉफ्टवेयर सर्वर में RAID1 पर दो हार्ड ड्राइव होते हैं। RAID1 के लिए डेटाबेस पर दो हार्ड ड्राइव हैं। और दो SSD उनके RAID1 पर भी हैं। सब कुछ 2U बॉक्स में है। मुख्य आधार SSD पर है, OS हार्ड ड्राइव पर है और वहां बैकअप है। Firewall में 1 / 2U बॉक्स में 6 पोर्ट हैं, हार्ड ड्राइव के अंदर और वैकल्पिक रूप से एक फ्लैश कार्ड है। सीरियल पोर्ट, वीजीए और बाहरी इलेक्ट्रॉनिक स्वास्थ्य मॉनिटर। आयन रेड हैट, सर्वर विन्यास, OpenBSD फ़ायरवॉल पर। लोहे के बक्से में मोजे और हाथ के सामान के सभी भरने के साथ एक अजीब कहानी है, लेकिन नहीं बिंदु नहीं था।

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

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

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

सिस्टम एक मानक जावा व्यापार प्रणाली (JVM, Tomcat, Struts, Apache Server, PostgreSQL, थोड़ा अधिक शेल और उम्मीद) के रूप में शुरू हुआ, लेकिन तेजी से विकास के लिए बड़ी संख्या में कोड जनरेटर बनाए गए थे। मानक कोड मानक कॉन्फ़िगरेशन फ़ाइलों से उत्पन्न होता है, इसलिए डेटाबेस के साथ संवाद करने की पहली तैयारी, संपूर्ण प्रस्तुति मुखौटा और उन्हें जोड़ने वाली सभी चीजें (व्यावसायिक तर्क का खोल) बनाई जाती हैं, यह सही निर्णय था, इसने अविश्वसनीय समय की बचत की। शाब्दिक रूप से, 3-4 दिनों के लिए हाथ से जो किया जाता है वह अब कुछ घंटों में किया जाता है। यह जल्द ही स्पष्ट हो गया कि इस कार्यक्रम में 'मानक' पर काम करने से काम नहीं चलेगा, आपको कई वास्तु निर्णय लेने की आवश्यकता है जो या तो काम करते हैं और निष्पादन की गति बढ़ाते हैं, या यह सब पूरी तरह से कवर किया जाता है, क्योंकि मैं उन उपयोगकर्ताओं के लिए उपयोग किया जाता हूं जो 200 के भीतर सिस्टम से प्रतिक्रिया की उम्मीद करते हैं -800 मिलीसेकंड, अधिक नहीं। लेकिन यहाँ रिपोर्ट पहले ही बननी शुरू हो गई है, जिसमें कम से कम 1 महीने के लगभग 15 स्टोर और समय अंतराल शामिल हैं, लेकिन जल्द ही रिपोर्ट में समय अंतराल एक साल तक बढ़ गया। यही है, लगभग 40 निदेशक / प्रबंधक 1 या सभी स्टोरों में उत्पाद श्रेणियों को बेचने में रुचि रखते थे और वे एक साथ 1-12 महीने के लिए डेटा देखना चाहते थे। मुझे यह प्रोसेस करना था कि ऑब्जेक्ट मॉडल का उपयोग कैसे किया जाता है, कोई भी रिपोर्ट के लिए 30 मिनट इंतजार नहीं करना चाहता है, और लोगों को इस तरह की चीज देने के लिए यह अशोभनीय है। एक महीने के काम के बाद, एक समाधान पाया गया, इसके अलावा, अब एक रिपोर्ट के लिए प्रत्येक उपयोगकर्ता का अनुरोध डेटाबेस में दर्ज किया गया था, सिस्टम के माध्यम से ही यह देखना संभव था कि कौन क्या करता है, कितना समय लगता है, वे किन मापदंडों का उपयोग करते हैं। यह कर्मचारियों के काम की निगरानी और लोगों को शिक्षित करने के लिए उपयोगी हो गया है, क्योंकि सिस्टम उपयोगकर्ताओं को उत्पादों को फ़िल्टर करने के लिए एक सरलीकृत रेगेक्स लिखने की अनुमति देता है, और रेगेक्स के लिए सबसे सरल समानता वाले लोगों को भी कुछ कठिनाइयां होती हैं। लेकिन सामान्य तौर पर, परिणाम सामान्य निकला, नब्बे प्रतिशत अनुरोध अब एक सेकंड से भी कम समय में, 10 सेकंड से कम समय में एक और 9 प्रतिशत, और दूसरे प्रतिशत में 1-2 मिनट लगे, जो पहले से ही आसान है।

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

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

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

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

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

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

यदि आपके कोई प्रश्न हैं, तो टिप्पणियों में लिखें, मैं जवाब दूंगा।