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