आंतरिक खरीद अनुरोध प्रणाली: रुकावटों से बचें

खरीद अनुरोध क्यों अटक जाते हैं

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

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

अधूरी जानकारी देरी बढ़ाती है

जब अनुरोध में हर व्यक्ति के लिए ज़रूरी जानकारी नहीं होती, तो खरीद अनुमोदन वर्कफ़्लो धीमा हो जाता है। आम कमियाँ हैं:

• आइटम का विवरण, मात्रा या सप्लायर का कोटेशन नहीं
• विभाग, लागत केंद्र या बजट राशि नहीं
• व्यावसायिक कारण या अपेक्षित डिलीवरी तारीख नहीं
• अनुमोदन या खरीद की ज़िम्मेदारी रखने वाला व्यक्ति तय नहीं
• टिप्पणियों, बदलावों या पुराने निर्णयों का रिकॉर्ड नहीं

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

एक रिकॉर्ड और स्पष्ट ज़िम्मेदारी

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

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

no-code खरीद ऐप इसे व्यावहारिक बनाता है, क्योंकि संचालन टीमों को फ़ॉर्म और स्प्रेडशीट अलग-अलग संभालने की ज़रूरत नहीं रहती। AppMaster एक ही ऐप में अनुरोध फ़ॉर्म, बजट फ़ील्ड, अनुमोदन लॉजिक और खरीदारों की कतार दे सकता है। हर अनुरोध की एक जगह, वर्तमान ज़िम्मेदार व्यक्ति और ऑर्डर तक पहुँचने लायक पर्याप्त जानकारी होनी चाहिए।

तय करें कि हर अनुरोध में क्या शामिल हो

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

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

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

दो तरह के अनुरोध रखें

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

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

किसी चीज़ का अनुरोध करने से पहले कर्मचारियों को सप्लायर ढूँढने के लिए बाध्य न करें। उन्हें पता हो सकता है कि स्टैंडिंग डेस्क चाहिए, लेकिन यह न पता हो कि कंपनी के नियमों के अनुकूल कौन-सा विक्रेता है। खरीद टीम यह काम बाद में पूरा कर सकती है।

हर आवश्यक फ़ील्ड का स्पष्ट कारण हो

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

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

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

अनुरोधों को तेज़ बनाने वाला कैटलॉग बनाएँ

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

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

उदाहरण के लिए, «Standard laptop» में मॉडल, अनुमोदित सप्लायर, 1,200 डॉलर की कीमत और तीन साल की वारंटी दी जा सकती है। अनुरोधकर्ता मात्रा चुनकर बताएगा कि इसका उपयोग कौन करेगा। खरीद टीम को हर बार वही उपयोगी जानकारी मिलेगी।

विकल्पों को सरल रखें

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

आइटम को सॉफ़्टवेयर, उपकरण, कार्यालय सामग्री और पेशेवर सेवाओं जैसी परिचित श्रेणियों में रखें। छोटे नाम और खोज सुविधा दें, ताकि लोग विवरण लिखना शुरू करने से पहले आइटम ढूँढ सकें।

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

अपवादों के लिए जगह रखें

कभी-कभी कर्मचारियों को ऐसी चीज़ चाहिए होगी जो सूची में नहीं है। खुला विकल्प रखें, लेकिन अगला कदम संभव बनाने लायक जानकारी माँगें: ज़रूरत, अनुमानित लागत, यदि ज्ञात हो तो सप्लायर और व्यावसायिक कारण।

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

AppMaster से बने no-code खरीद ऐप में कैटलॉग आइटम चुनने पर कीमत, सप्लायर और अनुरोध फ़ील्ड अपने-आप भरे जा सकते हैं। इससे बजट अनुमोदन प्रक्रिया को साफ़ डेटा मिलता है और खरीद ऑर्डर हैंडऑफ़ से पहले सुधार का काम घटता है।

अनुमोदन से पहले बजट जाँच जोड़ें

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

अनुरोधकर्ताओं के लिए जाँच सरल रखें। उन्हें अनुरोध की कुल राशि, उपलब्ध बजट और मंज़ूरी के बाद बचने वाली राशि दिखनी चाहिए। «यह अनुरोध बची हुई बजट राशि से 420 डॉलर अधिक है» जैसा संदेश प्रबंधक को बाद में ईमेल में समस्या खोजने से बचाता है।

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

अनुरोध की पूरी राशि जाँचें

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

अनुरोधकर्ता के फ़ॉर्म जमा करते ही और अनुमोदक को भेजने से पहले बजट अनुमोदन प्रक्रिया चलाएँ। इससे व्यर्थ समीक्षा से बचा जा सकता है और अनुरोधकर्ता लागत केंद्र ठीक कर सकता है, ऑर्डर घटा सकता है या अपवाद समझा सकता है।

no-code खरीद ऐप में यह एक विज़ुअल नियम हो सकता है: चुना हुआ लागत केंद्र पढ़ें, अनुरोध की कुल राशि की बची हुई बजट से तुलना करें और परिणाम को अनुरोध में सहेजें। AppMaster अनुरोध डेटा का मॉडल बना सकता है, Business Process Editor में लॉजिक तैयार कर सकता है और परिणाम आंतरिक फ़ॉर्म में दिखा सकता है।

बजट से अधिक अनुरोधों का मार्ग तय करें

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

बजट परिणाम और अपवाद से जुड़े निर्णय दर्ज करें। खरीद शुरू होने पर कर्मचारी देख सकेंगे कि खर्च मूल बजट में है या नहीं और अतिरिक्त राशि को किसने मंज़ूर किया। वित्त टीम यह भी समझा सकेगी कि लागत केंद्र योजना से बाहर क्यों गया।

ऐसे अनुमोदन मार्ग बनाएँ जिन्हें लोग समझ सकें

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

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

जोखिम कम हो तो मार्ग छोटा रखें। «सावधानी के लिए» अतिरिक्त अनुमोदक जोड़ने से सरल खरीद अनुमोदन वर्कफ़्लो देरी की श्रृंखला बन जाता है। हर अनुमोदक के पास मंज़ूर, अस्वीकार या अधिक जानकारी माँगने का स्पष्ट कारण होना चाहिए।

अनुमान लगाने योग्य नियम रखें

कर्मचारियों को अनुरोध भेजने से पहले पता होना चाहिए कि वह कहाँ जाएगा। स्पष्ट नियम अनुरोध अटकने पर विवाद भी कम करते हैं।

उदाहरण के लिए, कंपनी ऐसे नियम अपना सकती है:

• 500 डॉलर से कम के अनुरोध विभागीय प्रबंधक को जाएँ।
• 500 से 5,000 डॉलर तक के अनुरोध प्रबंधक और लागत केंद्र मालिक को जाएँ।
• सॉफ़्टवेयर और क्लाउड सेवा अनुरोध IT या सुरक्षा टीम को भी जाएँ।
• 5,000 डॉलर से अधिक के अनुरोध बजट मंज़ूरी के बाद खरीद टीम को जाएँ।
• पूंजीगत खरीद राशि चाहे जो हो, वित्त मालिक को जाए।

हर विभाग में नियम एक जैसे होना ज़रूरी नहीं है। बिक्री टीम को ग्राहक के सामने इस्तेमाल होने वाले टूल के लिए मंज़ूरी चाहिए हो सकती है, जबकि संचालन टीम को उपकरण की अतिरिक्त जाँच चाहिए। कंपनी में मूल लॉजिक एक जैसा रखें, ताकि कर्मचारियों को हर बार प्रक्रिया फिर से न सीखनी पड़े।

अनुपस्थिति की योजना बनाएँ और रिकॉर्ड पूरा रखें

हर अनुमोदक का बैकअप होना चाहिए। प्रबंधक छुट्टी पर हो तो सिस्टम नए अनुरोध किसी नामित विकल्प को भेजे या प्रशासक को लंबित काम फिर से सौंपने दे। अनुरोधकर्ताओं को ईमेल या चैट में किसी का पीछा नहीं करना चाहिए।

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

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

AppMaster में टीमें अनुरोध फ़ील्ड का मॉडल बना सकती हैं, विज़ुअल बिज़नेस प्रोसेस में अनुमोदन लॉजिक तैयार कर सकती हैं और अनुरोधकर्ताओं को वर्तमान स्थिति दिखा सकती हैं। ज़िम्मेदारी ईमेल थ्रेड में गायब होने के बजाय स्पष्ट रहती है।

अनुरोध प्रवाह चरण-दर-चरण बनाएँ

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

शुरुआत में Draft, Submitted, Approved, Rejected, Ordered और Received जैसी कम स्थितियाँ रखें। «समीक्षा लंबित» और «अनुमोदन की प्रतीक्षा» जैसे लगभग समान लेबल से बचें। लोग उनका अलग-अलग उपयोग करेंगे और रिपोर्टिंग खराब होगी।

अनुरोध Draft से शुरू होता है। अनुरोधकर्ता उसे सहेज, आइटम या मात्रा बदल या हटा सकता है। इस चरण में सिस्टम को सूचना नहीं भेजनी चाहिए और बजट आरक्षित नहीं करना चाहिए।

फ़ॉर्म जमा करने पर स्थिति Submitted हो जाती है। कीमत, सप्लायर की जानकारी और अनुरोधित राशि को लॉक करें, जब तक कि कोई अनुरोध बदलाव के लिए वापस न भेजे। अनुमोदक मंज़ूर, अस्वीकार या छोटी टिप्पणी के साथ वापस भेज सकता है।

मंज़ूरी के बाद अनुरोध खरीद टीम को दें। कर्मचारी तभी इसे Ordered करें जब वे खरीद ऑर्डर बना या दे चुके हों। खर्च की अनुमति मिलना इस बात का प्रमाण नहीं है कि किसी ने आइटम खरीद लिया है।

सामान पहुँचने, सेवा शुरू होने या सदस्यता की पुष्टि होने पर प्राप्तकर्ता अनुरोध को Received करे। इससे वित्त टीम और अनुरोधकर्ताओं को प्राप्त चीज़ों का भरोसेमंद रिकॉर्ड मिलता है।

हर भूमिका के लिए स्पष्ट कार्रवाई दें

सरल आंतरिक खरीद अनुरोध प्रणाली में स्थिति बदलने की ज़िम्मेदारी स्पष्ट होनी चाहिए। हर उपयोगकर्ता को जमा किए गए हर अनुरोध में बदलाव की अनुमति न दें।

• अनुरोधकर्ता Draft बना, अनुरोध जमा और वापस आए अनुरोध ठीक कर सकते हैं।
• प्रबंधक और बजट मालिक कारण के साथ अनुरोध मंज़ूर, अस्वीकार या वापस कर सकते हैं।
• खरीद कर्मचारी सप्लायर की जानकारी, खरीद ऑर्डर का विवरण और Ordered स्थिति दर्ज कर सकते हैं।
• प्राप्ति की ज़िम्मेदारी वाले कर्मचारी डिलीवरी की पुष्टि कर अनुरोध को Received कर सकते हैं।
• वित्त कर्मचारी पूरा इतिहास देख सकते हैं और सीमित फ़ील्ड, जैसे लेखा संदर्भ, ठीक कर सकते हैं।

प्रशासक को कंपनी छोड़ने वाले अनुमोदक या डुप्लिकेट अनुरोध जैसे अपवाद संभालने चाहिए। हर स्थिति बदलाव का ऑडिट रिकॉर्ड रखें, जिसमें किसने, कब और किस टिप्पणी के साथ बदलाव किया।

कार्रवाई की ज़रूरत होने पर सूचना दें

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

किसी के मंज़ूर, अस्वीकार या वापस करने पर अनुरोधकर्ता को सूचना दें। अस्वीकार या वापसी के लिए टिप्पणी अनिवार्य करें। «इस तिमाही में बजट उपलब्ध नहीं है» दिशा देता है, जबकि «नहीं» नहीं देता।

अंतिम मंज़ूरी के बाद खरीद टीम को सूचना मिलनी चाहिए। खरीद टीम द्वारा अनुरोध को Ordered और Received करने पर अनुरोधकर्ता को अपडेट मिले। तय समय तक कोई कार्रवाई न होने पर वर्तमान ज़िम्मेदार व्यक्ति को याद दिलाएँ और बैकअप अनुमोदक को प्रति भेजें।

AppMaster में no-code खरीद ऐप Data Designer में स्थितियों का मॉडल बना सकता है और Business Process Editor में अनुमत बदलाव लागू कर सकता है। हर हैंडऑफ़ रिकॉर्ड पर रहता है और किसी व्यक्ति की याददाश्त पर निर्भर नहीं करता।

उदाहरण: सॉफ़्टवेयर सदस्यता का अनुरोध

मार्केटिंग प्रबंधक माया को सोशल मीडिया प्लानिंग टूल की 15 सदस्यताएँ चाहिए। वह आंतरिक खरीद अनुरोध प्रणाली खोलकर खुला अनुरोध बनाने के बजाय सॉफ़्टवेयर कैटलॉग से टूल चुनती है।

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

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

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

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

समन्वयक खरीद ऑर्डर नंबर दर्ज कर अनुरोध को Ordered करता है। माया खरीद टीम से पूछे बिना अपडेट देख सकती है। सप्लायर द्वारा 15 लाइसेंस की पुष्टि करने पर समन्वयक अनुरोध को Received करता है और खाता संभालने वाले व्यक्ति का नाम दर्ज करता है।

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

खरीदारी धीमी करने वाली गलतियाँ

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

हर अनुरोध ऊपर भेजना

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

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

अनुमोदित अनुरोधों में चुपचाप बदलाव होने देना

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

महत्वपूर्ण बदलावों के लिए नियम तय करें। 10 लाइसेंस से 12 या 500 डॉलर से 1,200 डॉलर का बदलाव अनुरोध को संबंधित समीक्षक के पास वापस भेजना चाहिए। डिलीवरी संपर्क जैसी छोटी टिप्पणी को खरीद अनुमोदन वर्कफ़्लो फिर शुरू किए बिना बदला जा सकता है।

no-code खरीद ऐप बदलावों का इतिहास रख सकता है और नियंत्रित फ़ील्ड बदलने पर अनुमोदन फिर खोल सकता है। इससे वित्त टीम अनुमोदित राशि और इनवॉइस की तुलना करते समय होने वाले आश्चर्य से बचती है।

अनुरोध बहुत जल्दी बंद करना

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

Approved, Ordered, Received और Closed जैसी स्पष्ट स्थितियाँ रखें। अनुरोध को Closed तभी करें जब खरीद टीम ऑर्डर का विवरण दर्ज कर हैंडऑफ़ की पुष्टि कर दे। अनुमोदित वार्षिक सदस्यता तब तक Approved रहनी चाहिए, जब तक खरीदार सप्लायर ऑर्डर या नवीनीकरण संदर्भ दर्ज न कर दे।

इस अंतर से रिपोर्टिंग अधिक भरोसेमंद होती है। टीमें देख सकती हैं कि कौन-से अनुमोदित अनुरोधों पर अभी कार्रवाई बाकी है, कौन-से ऑर्डर डिलीवरी की प्रतीक्षा में हैं और कौन-सी खरीद पूरी हो चुकी है।

लॉन्च से पहले त्वरित जाँच

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

हर अनुरोध का एक स्पष्ट मालिक और दिखाई देने वाली स्थिति होनी चाहिए। जब ज़िम्मेदारी अनुरोधकर्ता से प्रबंधक या खरीदार तक जाए, तो मालिक भी बदले। स्थिति लेबल Draft, Submitted, Approved, Rejected या Handed to purchasing जैसे स्पष्ट होने चाहिए।

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

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

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

मंज़ूरी के बाद होने वाले बदलावों का भी परीक्षण करें। अनुरोधकर्ता 10 मॉनिटर की जगह 15 कर सकता है या सप्लायर कीमत बढ़ा सकता है। खरीद अनुमोदन वर्कफ़्लो को अनुरोध फिर से अनुमोदन में भेजना चाहिए या स्पष्ट रूप से बताना चाहिए कि किन बदलावों की नई समीक्षा नहीं चाहिए। चुपचाप बदलाव बाद में विवाद पैदा करते हैं।

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

अगले कदम चुनें

ऐसे एक विभाग से शुरुआत करें जहाँ खरीद बार-बार होती हो और अनुमोदन श्रृंखला संभालने योग्य हो। IT सॉफ़्टवेयर, कार्यालय सामग्री या Marketing सदस्यताएँ व्यावहारिक शुरुआती क्षेत्र हैं। उस समूह को आम आइटम, अनुमानित कीमत और खरीद टीम के लिए ज़रूरी जानकारी वाला छोटा कैटलॉग दें।

पहला संस्करण केंद्रित रखें। अनुरोधकर्ता स्पष्ट ज़रूरत भेज सके, अनुमोदक लागत और बजट स्थिति देख सके और खरीद टीम को मंज़ूरी के बाद पूरा अनुरोध मिल सके। मूल मार्ग भरोसेमंद ढंग से चलने के बाद ही असामान्य अनुरोध प्रकार जोड़ें।

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

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

AppMaster टीमों को खाली तकनीकी प्रोजेक्ट से शुरुआत किए बिना no-code खरीद ऐप बनाने में मदद कर सकता है। टीमें कर्मचारी अनुरोध फ़ॉर्म बना सकती हैं, बजट जाँच और अनुमोदन मार्गों के लिए Business Process Editor का उपयोग कर सकती हैं और प्रबंधकों तथा खरीद कर्मचारियों के लिए अलग स्क्रीन बना सकती हैं। Data Designer कैटलॉग आइटम, विभाग, सप्लायर, बजट और अनुरोधों को एक जगह रख सकता है।

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