हमारे पास ईआरपी है, क्या अब भी किसी विशेष वाहन की आवश्यकता है?

ईआरपी का अस्तित्व प्रक्रिया के पूरा होने के समान नहीं है

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

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

सबसे पहले मौजूदा सिस्टम में विकल्पों की जांच करें

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

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

एक निजी वाहन कौन सी कमी पूरी कर सकता है?

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

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

डेटा स्वामित्व और कनेक्शन सीमा निर्णायक हैं

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

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

सुरक्षा और रखरखाव बाद में नहीं जोड़ा जाता है

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

आपको कैसे पता चलेगा कि यह आवश्यक है?

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

अक्सर पूछे जाने वाले सवाल

यदि ईआरपी है तो क्या विशेष वाहन अनावश्यक है?

हमेशा नहीं. सबसे पहले, मौजूदा मॉड्यूल और अनुकूलन संभावनाओं की जांच की जाती है। यदि कोई संकीर्ण प्रक्रिया अंतर रह जाता है, तो विशेष उपकरण उसे भर सकता है।

क्या निजी वाहन को ईआरपी की जगह लेनी चाहिए?

यह एक अलग और व्यापक निर्णय है। ईआरपी में विजेट के लिए मास्टर रिकॉर्ड रखने और डेटा स्वामित्व को स्पष्ट रखने से अक्सर दायरा अधिक प्रबंधनीय रहता है।

पायलट में क्या चेक किया जाता है?

डेटा मिलान, पहुंच प्राधिकरण, त्रुटि व्यवहार, पुनरावृत्ति रोकथाम और रखरखाव जिम्मेदारी का मूल्यांकन वास्तविक व्यावसायिक उदाहरणों के साथ किया जाता है।