हब्रो आत्महत्या। 1 सी में नियोजन का दर्द

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

यदि आपने अनुभव किया है, या अब 1 सी में योजना बनाने के दर्द का अनुभव कर रहे हैं, तो चलो एक साथ बीमार हो जाते हैं और ठीक होने की कोशिश करते हैं।

लेख मुख्य रूप से एससीपी के बारे में लिखा गया है। ईआरपी में समस्याओं का एक हिस्सा हटा दिया गया था (एक ही समय में नए जोड़ते हुए), लेकिन दर्द आज तक बना हुआ है।

तो चलिए चलते हैं।

सुरक्षा

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

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

मैंने, आपकी तरह, भी ऐसी रिपोर्ट की। प्रश्न के सकल उत्तर के लिए, रिपोर्ट काफी उपयुक्त है, लेकिन कठोर उत्तर की आवश्यकता किसे है? लोगों के पास व्यापार है, सवाल का जवाब पैसे की कीमत, अशिक्षित संपत्ति, नकद अंतराल, ग्राहकों के साथ संबंधों पर निर्भर करता है।

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

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

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

योजना सहायक

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

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

दूसरा महत्वपूर्ण दोष यह है कि सहायक इस सवाल का जवाब नहीं देता है कि "किस कीमत पर प्रदान किया गया है?"। यह केवल वही देता है जो गायब है, अर्थात्। साथ के प्रश्न का उत्तर देता है, मुख्य को छोड़ देना।

आरक्षण और आवास

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

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

आशा एक दस्तावेज "माल का आरक्षण" के रूप में भड़की - यह आपको एक बैठक में सभी भंडार को समायोजित करने की अनुमति देता है। रिलीज, स्थानांतरण, अधिक प्रासंगिक संसाधनों पर कब्जा - अर्थात् ऊपर वर्णित सभी नुकसानों को समाप्त करता है

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

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

इसके अलावा, नियोजन सहायक के रूप में एक ही दोष - अतिरेक, झुकाव। AWP, आपको लगातार उपयोग करने की आवश्यकता है। इसमें जाओ, इसका पालन करो, कुछ दबाओ। बिग डिस्पैचर, फिर से, की जरूरत है।

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

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

लेकिन मैं केवल यह जानना चाहता हूं कि मेरे साथ क्या प्रदान किया गया है, क्या प्रदान किया गया है, और क्या खरीदा जाना चाहिए।

एनालॉग

विषय इतना काट दिया गया है कि शायद यह सम्मेलनों में भी नहीं आता है। सालों बीत जाते हैं, गाड़ी नहीं चलती।

जहां भी मैंने योजना के साथ काम किया, मुझे एनालॉग्स पर विचार करना था।

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

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

वास्तविक जीवन में, एनालॉग्स के लिए लेखांकन, ज़ाहिर है, अधिक कठिन है।

उदाहरण के लिए, विनिमेयता ग्राहक पर निर्भर हो सकती है - एक को एक अलग स्टील की जरूरत है, दूसरे को नाक के खून 40X की जरूरत है। एक चीन में बना है, दूसरा देशभक्त है।

लेकिन यह सब है - सरल मामले जब एनालॉग्स एक से जुड़े होते हैं।

यह अधिक कठिन होता है। उदाहरण के लिए, बहुलक पैकेज बनाते समय, उपयुक्त चौड़ाई की एक फिल्म ली जाती है। यदि ग्राहक ने 1000 मिमी चौड़ी पैकेजिंग का रोल ऑर्डर किया है, तो हम 1100 मिमी की चौड़ाई लेते हैं, किनारों को 50 मिमी (ताकि यह सम है) तक कट जाए, और हर कोई खुश हो। लेकिन एक स्थिति थी जब हमारे पास 1100 व्यापक फिल्म नहीं है, और 1105 मिमी है। बेशक, हम भाप स्नान नहीं करते हैं और इसे लेते हैं - बस थोड़ा और बेकार होगा। और हम 1110 मिमी ले सकते हैं, हम 1115 मिमी ले सकते हैं, हम 1300 भी ले सकते हैं यदि जलने का क्रम और ग्राहक हमारे पसंदीदा हैं।

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

संक्षेप में, नरक नारकीय है। लेकिन मैं चाहता हूं कि इसे किसी भी तरह ध्यान में रखा जाए, और सवाल का जवाब "क्या हमें प्रदान किया गया है या नहीं?" सिस्टम ने दिया।

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

लचीलापन

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

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

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

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

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

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

मुझे आपके बारे में पता नहीं है, लेकिन इस तुलना में ग्रेट नथिंग करीब है।

कस्टम मेटाडेटा ऑब्जेक्ट

खैर, यहाँ बताने के लिए वास्तव में कुछ भी नहीं है। कोई भी जोड़ा मेटाडेटा ऑब्जेक्ट किसी भी योजना या संपार्श्विक योजना में नहीं आता है।

Makeshift मेटाडेटा ऑब्जेक्ट्स के उदाहरण, और मैं, और आप एक मिलियन जानते हैं। यदि आप उद्योग समाधान के साथ एससीपी को जोड़ते हैं, तो घर-निर्मित वस्तुएं स्वयं दिखाई देंगी। उनमें से कोई भी योजना में भाग नहीं लेगा, और विन्यासकर्ता यहां अपरिहार्य है।

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

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

सारांश

इससे पहले, मैंने अक्सर वाक्यांश सुना है कि नियोजन प्रत्येक उद्यम के लिए एक अनूठी प्रक्रिया है, और इसके सभी विकल्पों के लिए एक मानक समाधान का उत्पादन करना असंभव है।

इस वाक्यांश के बाद, मुझे कार्यों के एक वर्ग के रूप में योजना बनाना पसंद आया।

एक तरफ, मानक समाधान बनाने की आवश्यकता से वाक्यांश 1C (और सामान्य रूप से किसी भी डेवलपर) को बचाता है।

दूसरी ओर, वाक्यांश घुसपैठिये को प्रेरित करता है - आओ, कार्य करें, इस क्षेत्र में कोई कानून, नियम, सही और गलत निर्णय नहीं हैं! यह करो!

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

और सभी इस वाक्यांश के कारण। प्रत्येक बार बनाएं, क्योंकि कोई मानक समाधान नहीं है।

तब उसने केवल यह कहा कि वाक्यांश गलत था, अनसुना, इसमें कुछ गायब था।

क्लाइंट के लिए कोई मानक समाधान नहीं है। या दूसरे तरीके से - उपयोगकर्ता के लिए कोई बॉक्सिंग समाधान नहीं है। दुनिया में ऐसा कोई कार्यक्रम नहीं है जिसमें उपयोगकर्ता अपनी खुद की योजना बनाता है। एक कार्यक्रम है जहां उपयोगकर्ता स्वयं लेखांकन करेगा। लेखांकन हम सभी को यह पता होगा।

लेकिन वे एकल कार्यान्वयन में समृद्ध नहीं हैं, वहां 1 सी प्रोग्रामर भी हैं। उपयोगकर्ता - वह केवल बटन दबाने के लिए जानता है, और फिर भी वह हर समय गलत है। प्रोग्रामर, वह कोड लिखता है, वह लेआउट योजना, और डेटा भंडारण योजना जानता है, और मेटाडेटा देखता है, और योजना लक्ष्य जानता है, और प्रक्रियाएं जानता है ... क्या आप समझते हैं?

उपयोगकर्ता के लिए नियोजन कार्य के लिए कोई मानक समाधान नहीं है, लेकिन प्रोग्रामर के लिए। प्रोग्रामर के लिए एक विशिष्ट नियोजन कार्य समाधान होना चाहिए । उपकरण,

• अमूर्त का एक निश्चित स्तर (लेकिन एक विन्यासकर्ता के रूप में नहीं, निश्चित रूप से);
• नियोजन कार्यों के बुनियादी एल्गोरिदम को हल करता है ताकि प्रत्येक कार्यान्वयन पर उनके बारे में चिंता न करें;
• नियोजन उद्देश्यों के लिए सभी आवश्यक सिस्टम डेटा का उपयोग करने में सक्षम;
• जो सेटअप के लिए प्रोग्रामिंग की आवश्यकता नहीं है, लेकिन यह भी एक अश्लील पहेली में पर्ची नहीं करता है।

सामान्य तौर पर, आपको प्रोग्रामर के लिए प्रोग्रामर द्वारा बनाए गए टूल की आवश्यकता होती है।

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

रूपांतरण लगभग पूरी तरह से उन मानदंडों को पूरा करता है जो मैंने योजना प्रणाली को प्रस्तुत किया था:

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

* - यहाँ सिर्फ सच नहीं है, रूपांतरण में प्रोग्रामिंग आमतौर पर आवश्यक है। लेकिन बहुत सारे उदाहरण हैं जब यह आवश्यक नहीं है।

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

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

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

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

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

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

उपरोक्त सभी लेखक की निजी राय है, ज़ाहिर है।

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