ख़रीद अनुरोध और अनुमोदन सीमाएँ: कौन किस पर हस्ताक्षर करता है?

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

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

ख़रीद अनुरोध: वह दस्तावेज़ जिस पर उसके बाद का सब कुछ टिका है

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

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

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

अनुमोदन मैट्रिक्स: केवल राशि काफ़ी नहीं है

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

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

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

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

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

दो चोर रास्ते जिन्हें सिस्टम को बंद करना होगा

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

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

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

तत्काल ख़रीद: चोर रास्ते के बजाय एक घोषित रास्ता

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

ईमानदार तरीक़ा ऐसा सिस्टम है जो मानता है कि आपात स्थितियाँ होती हैं और उन्हें स्पष्ट शर्तों के साथ एक घोषित रास्ता देता है:

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

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

Origami का दृष्टिकोण

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

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

इस सप्ताह के लिए एक अभ्यास: अपना मैट्रिक्स एक पन्ने पर बनाएँ

किसी भी सिस्टम से पहले, वह मैट्रिक्स लिख डालें जिससे आपकी कंपनी आज काम करती है, भले ही वह कभी लिखा न गया हो। मालिक इसे संचालन प्रबंधक और वित्त प्रबंधक के साथ एक या दो बैठकों में कर सकता है:

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

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

अगले भाग में

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

स्रोत

• इलेक्ट्रॉनिक लेनदेन कानून, 8/3/1428H दिनांकित शाही फ़रमान संख्या M/18, मंत्रिपरिषद के विशेषज्ञ ब्यूरो का संस्करण — अनुच्छेद 5 (इलेक्ट्रॉनिक लेनदेन, रिकॉर्ड और हस्ताक्षरों का बाध्यकारी प्रभाव) और अनुच्छेद 9 (इलेक्ट्रॉनिक लेनदेन को साक्ष्य के रूप में स्वीकार करना, और उनके आकलन में किन बातों को तौला जाता है)।
• वैट कार्यान्वयन विनियम, ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) (आधिकारिक अरबी पाठ) — अनुच्छेद 66(1) (इनवॉइस, रिकॉर्ड और लेखा दस्तावेज़ों को उस कर अवधि की समाप्ति से कम से कम छह वर्ष तक रखना जिससे वे संबंधित हैं)।